5 Frame structure and format of fields

24.2503GPPProtocol for Reliable Data ServiceRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

The peer-to-peer transfers using RDS shall conform to the frame format as shown in figure 5.1-1. The frame header shall consist of the Address and Control field and is a minimum of 1 octet and a maximum of 3 octets long. The Information field is of variable length.

8	7	6	5	4	3	2	1

Address and Control field
(variable length, max. 3 octets)


Information field
(variable length, max. N201 octets)

Figure 5.1-1: RDS frame format

5.2 Address and Control field

5.2.1 Address and Control field format

The Address and Control field identifies the type of frame and consists of minimum of 1 octet and maximum of 3 octets. The following types of control field frames are specified:

– confirmed information transfer (I frame);

– supervisory functions (S frame);

– unconfirmed information transfer (UI frame); and

– control functions (U frame).

The address and control field format for RDS is shown in figure 5.2.1-1.The description of address and control field bits is shown in Table 5.2.1-1.

Figure 5.2.1-1: Address and Control field format

Table 5.2.1-1: Address and Control field bits description

Control field bits	Description
A	Acknowledgement request bit
M_n	Unnumbered function bit
N(R)	Receive sequence number
N(S)	Send sequence number
N(U)	Unconfirmed sequence number
S_n	Supervisory function bit
R_n	Selective acknowledgement bitmap bit
PD	Protocol Discriminator bit
C/R	Command / Response bit
ADS	Address bit
Source Port	Source port number
Destination Port	Destination port number
X	Spare bit

5.2.2 Protocol Discriminator bit (PD)

The PD bit indicates whether a frame is an RDS frame or belongs to a different protocol. RDS frames shall have the PD bit set to 0. If a frame with the PD bit set to 1 is received, then it shall be treated as an invalid frame.

5.2.3 Address bit (ADS)

The ADS bit controls if the Source Port and Destination Port are included in the frame format. When a single application on UE side conducts data transfer with a single application on networkside, the source and destination port numbers need not be used. The source and destination port numbers enable multiple applications on the UE side to simultaneously communicate with their peer entities on the network side using the same PDN connection or PDU session. Source Port and Destination Port are included in the frame format only if the ADS bit is set to 1.

5.2.4 Source port number (Source Port)

When a UE application starts to use the PDN connection or a PDU session to transmit RDS frames, the UE and the network establish which source port number will be used for the application on the UE side for MO traffic and which destination port number will be used for the application intended to receive the frames on the network side. Similarly for MT traffic when an application in the network starts to use the PDN connection or PDU session to transmit RDS frames, the UE and the network establish which source port number will be used for the application on the network side and which destination port number will be used for the application intended to receive the frames on the UE side. Applications on the originator side and their peer entities on receiver side can synchronize port numbers using port management functionality as described in subclause 5.4.2.6 or using means outside the scope of this specification.

Source Port is included only if the ADS bit is 1. Source Port shall have values from 0 to 15.

5.2.5 Destination port number (Destination Port)

The Destination Port is used to identify the destination application on the receiver that is receiving the frame.

Destination Port is included only if the ADS bit is 1. Destination Port shall have values from 0 to 15.

5.2.6 Information transfer frame – I

The I frame shall be used to perform an information transfer between peer entities with acknowledgement. Each I frame has a send sequence number N(S), a receive sequence number N(R) and an acknowledgement request bit A, that may be set to 0 or 1. The use of N(S), N(R), and A is defined in clause 6.

Each I frame also contains supervisory function bits S(n) and the Selective Acknowledgement bitmap R(n) which are defined in subclause 5.3.2.

5.2.7 Supervisory frame – S

The S frame shall be used to perform supervisory control functions such as acknowledge I frames. The supervisory frame has supervisory function bits S(n) that are used for encoding commands and responses which perform the supervisory control functions. Each supervisory frame has a receive sequence number N(R) and an acknowledgement request bit A, that may be set to 0 or 1. In acknowledged operation, all I and S frames contain R(n), the Selective Acknowledgement bitmap. The commands and responses are defined in subclause 5.4 and the use of S(n), N(R), A and R(n) is defined in clause 6.

5.2.8 Unconfirmed Information frame – UI

The UI frame shall be used to perform an information transfer between peer entities without acknowledgement. The UI frames contain N(U), the unconfirmed sequence number of transmitted UI frames. No verification of sequence numbers is performed for UI frames.

5.2.9 Unnumbered frame ‑ U

The U frame shall be used to provide additional link control functions. Each U frame has Unnumbered function bits M(n) that are used to encode link control commands and response. The U frame has Command/Response bit (C/R) that identifies a U frame as either a command or a response. The U fame contains no sequence number. The commands and responses are defined in subclause 5.4 and the use of M(n) is defined in clause 6.

5.2.10 Command / Response bit (C/R)

The C/R bit identifies a frame as either a command or a response. The UE side shall send commands with the C/R bit set to 0, and responses with the C/R bit set to 1. The network side shall do the opposite; i.e., commands are sent with C/R set to 1, and responses are sent with C/R set to 0. The combinations for the network side and UE side are shown in table 5.2.10-1.

Table 5.2.10-1: C/R field bit usage

Type	Direction	C/R value
Command	Network side to UE side	1
Command	UE side to Network side	0
Response	Network side to UE side	0
Response	UE side to Network side	1

5.3 Control field parameters and associated state variables

The various parameters associated with the control field frames are described in this subclause.

5.3.1 Acknowledgement request bit (A)

All I and S frames contain the Acknowledgement Request (A) bit.

The A bit set to 1 is used to solicit an acknowledgement (i.e., an I frame or S frame) from the receiver. The A bit set to 0 is used to indicate that the receiver is not requested to send an acknowledgement.

5.3.2 Acknowledged operation variables and parameters

5.3.2.1 Send state variable V(S)

In acknowledged operation, each originator shall have an associated send state variable V(S) when using I frames. V(S) denotes the sequence number of the next in-sequence I frame to be transmitted. V(S) can take on the value 0 through (MAX SEQUENCE NUMBER -1). The value of V(S) shall be incremented by 1 with each successive I frame transmission, and shall not exceed acknowledge state variable V(A) by more than the maximum number of outstanding I frames k. The value of k may be in the range 1  k  (MAX SEQUENCE NUMBER/2 -1). V(S) shall not be incremented when an I frame is retransmitted.

5.3.2.2 Acknowledge state variable V(A)

In acknowledged operation, each peer originator shall have an associated acknowledge state variable V(A) when using I frame and supervisory frame commands and responses. V(A) identifies the first I frame in the transmit window, so that V(A) ‑ 1 equals N(S) of the last in-sequence acknowledged I frame. V(A) can take on the value 0 through (MAX SEQUENCE NUMBER -1). The value of V(A) shall be updated by the valid N(R) values received from its peer (see subclause 5.3.2.5). A valid N(R) value is in the range V(A)  N(R)  V(S).

5.3.2.3 Send sequence number N(S)

In acknowledged operation, only I frames contain N(S), the send sequence number of transmitted I frames. At the time that an in-sequence I frame is designated for transmission, the value of N(S) is set equal to the value of the send state variable V(S).

5.3.2.4 Receive state variable V(R)

In acknowledged operation, each receiver shall have an associated receive state variable V(R) when using I frame and supervisory frame commands and responses. V(R) denotes the sequence number of the next in-sequence I frame expected to be received. V(R) can take on the value 0 through (MAX SEQUENCE NUMBER -1). The value of V(R) shall be incremented by one with the receipt of an error-free, in-sequence I frame whose send sequence number N(S) equals V(R).

5.3.2.5 Receive sequence number N(R)

In acknowledged operation, all I frames and S frames contain N(R), the expected send sequence number of the next in-sequence received I frame. At the time that a frame of the above types is designated for transmission, the value of N(R) is set equal to the value of the receive state variable V(R). N(R) indicates that the receiver transmitting the N(R) has correctly received all I frames numbered up to and including N(R) ‑ 1.

5.3.2.6 Selective Acknowledgement (SACK) bitmap R(n)

In acknowledged operation, all I frames and S frames contain R(n), the SACK bitmap. At the time that a S frame is designated for transmission, the value of each bit R(n) in the bitmap shall be set to 0 or 1 depending on whether I frame number N(R) + n has been received or not. R(n) = 1 indicates that the receiver transmitting the S frame has correctly received I frame number N(R) + n. R(n) = 0 indicates that the receiver transmitting the S frame has not correctly received I frame number N(R) + n. The SACK bitmap contains (k) bits.

5.3.3 Unacknowledged operation variables and parameters

5.3.3.1 Unconfirmed send state variable V(U)

Each peer entity shall have an associated unconfirmed send state variable V(U) when using UI frame commands. V(U) denotes the sequence number of the next UI frame to be transmitted. V(U) can take on the value 0 through 7. The value of V(U) shall be incremented by 1 with each successive UI frame transmission.

5.3.3.2 Unconfirmed sequence number N(U)

Only UI frames contain N(U), the unconfirmed sequence number of transmitted UI frames. At the time that a UI frame is designated for transmission, the value of N(U) is set equal to the value of the unconfirmed send state variable V(U).

5.3.3.3 Unconfirmed receive state variable V(UR)

Each peer entity shall have an associated unconfirmed receive state variable V(UR) when using UI frame commands. V(UR) denotes the sequence number of the next in-sequence UI frame expected to be received. V(UR) can take on the value 0 through 7.

5.3.3.4 Other parameters and variables

The only other parameter defined for unacknowledged operation is the number of octets (N201) in the information field of the UI frame. See subclause 6.4.6.

5.4 Commands and responses

5.4.1 General

The following commands and responses are used by the UE side and Network side as shown in table 5.4.1-1. Each link connection shall support the appropriate set of commands and responses for the type of operation desired.

Table 5.4.1-1: Commands and responses

Frame	Commands	Responses	Encoding
	Commands	Responses	S1	S2	M4	M3	M2	M1
S Frame or I Frame	SACK	SACK	1	1	–	–	–	–
U Frame	ERROR	ERROR	–	–	0	0	0	1
U Frame	DISCONNECT	–	–	–	0	1	0	0
U Frame	–	ACCEPT	–	–	0	1	1	0
U Frame	SET_ACK_MODE	–	–	–	0	1	1	1
U Frame	SET_PARAMETERS	SET_PARAMETERS	–	–	1	0	1	1
U Frame	MANAGE_PORT	MANAGE_PORT	–	–	1	0	1	0

5.4.2 Unnumbered (U) frames

5.4.2.1 SET_ACK_MODE command

The originator shall use the SET_ACK_MODE command to initiate acknowledged operation between the UE and network.

The receiver shall confirm acceptance of a SET_ACK_MODE command by the transmission of an ACCEPT response. Upon acceptance of SET_ACK_MODE command, the send state variable V(S), acknowledge state variable V(A), and receive state variable V(R), shall be set to 0. The transmission of a SET_ACK_MODE command indicates the clearance of any exception conditions.

Previously transmitted I frames that are unacknowledged when this command is sent shall be discarded. It is the responsibility of higher layers to recover from the possible loss of the contents of such I frames.

5.4.2.2 DISCONNECT command

The DISCONNECT command shall be transmitted in order to terminate the acknowledged operation.

No information field is permitted with the DISCONNECT command. Prior to executing the command, the receiver side receiving the DISCONNECT command shall confirm the acceptance of a DISCONNECT command by the transmission of an ACCEPT response. The originator that sends the DISCONNECT command shall terminate the acknowledge mode operation when it receives the ACCEPT or ERROR response.

Previously transmitted I frames that are unacknowledged when this command is executed shall remain unacknowledged and shall be discarded. It is the responsibility of higher layers to recover from the possible loss of the contents of such I frames.

5.4.2.3 ACCEPT response

The ACCEPT response shall be used by the originator to acknowledge the receipt and acceptance of the SET_ACK_MODE or DISCONNECT commands. The SET_ACK_MODE or DISCONNECT commands are acted upon only after the ACCEPT response is transmitted.

5.4.2.4 ERROR command / response

The ERROR unnumbered command shall be used by the originator to report to the receiver that the originator is in a state such that acknowledged operation cannot be performed. The receiver shall transmit an ERROR response to any valid command received that it cannot execute. No information field is permitted with the ERROR command or ERROR response.

5.4.2.5 SET_PARAMETERS command / response

The SET_PARAMETERS command and response is used to negotiate values of parameters between originator and receiver in both acknowledged and unacknowledged mode of transfer. These parameters shall include the version of the RDS.

If the originator wants to negotiate the value of parameters, the originator shall send a SET_PARAMETERS command including the set of parameters along with their values to the receiver. The receiver shall send a SET_PARAMETERS response, either confirming these parameter values by returning the requested values, or proposing different ones in their place. Both, the originator and the receiver shall use the negotiated values after the completion of the negotiation process.

Table 5.4.2.5-1 lists the negotiable RDS layer parameters. Figure 5.4.2.5-1 shows the SET_PARAMETERS field format. A parameter item consists of Type and Length octets followed by the value of that parameter. The Length octet indicates the number of octets that the value actually occupies.

Figure 5.4.2.5-1: SET_PARAMETERS field format

Table 5.4.2.5-1: RDS layer parameters

Parameter Name	Type	Length	Format (87654321)	Range
RDS_Version	0	1	bbbbbbbb	0 through 255

5.4.2.6 MANAGE_PORT command / response

5.4.2.6.1 General

The originator and receiver may support the handling specified in subclause 5.4.2.6.

The MANAGE_PORT command and response is used to manage association of applications with source and destination port numbers between originator and receiver and negotiate the serialization format that will be used by the application in both acknowledged and unacknowledged mode of transfer. The MANAGE_PORT command and response can be used to:

– reserve a combination of source and destination port numbers for use with a specific application. Applications can also additionally reserve the serialization format to be used;

– release a combination of source and destination port numbers that are reserved;

– query the list of port numbers that are reserved for use with a specific application. Applications can also additionally query the serialization format; and

– notify the list of port numbers that are reserved for use with a specific application. The serialization format used by the applications can also be additionally notified.

Port number 0 shall not be reserved at the originator or receiver. If an application at the originator communicates with multiple applications at the receiver, then the application does not reserve a port number at destination and shall set the Destination Port to 0. The ADS bit in the U frame header of MANAGE_PORT command and response is set to 0. Table 5.4.2.6.1-1 lists the parameters used in MANAGE_PORT command and response frames.

Table 5.4.2.6-1: MANAGE_PORT parameters

Action (Bits 1 to 4, octet 1)

This field indicates the operation that the originator or receiver performs as part of MANAGE_PORT command or response and can have the following values

Bits

4 3 2 1

0 0 0 1 Reserve port

0 0 1 0 Release port

0 0 1 1 Query port

0 1 0 0 Notify port

0 1 0 1 Reserve port and serialization format

0 1 1 0 Query port and serialization format

0 1 1 1 Notify port and serialization format

All other values are reserved.

Application Id

This field shall be encoded as a sequence of a sixteen octet OS Id field, a one octet OS App Id length field, and an OS App Id field. The OS Id is the operating system Identifier and it contains a UUID as specified in IETF RFC 4122 [3]. The OS App Id field contains an OS specific application identifier of variable length octets.

Serialization Format

This field is used to indicate the serialization format used by the application and shall be encoded as a bitmap of one octet as indicated below:

Status

This field is used only in the response frame in the direction from the receiver to the originator. It specifies the status of the operation and can have the following values:

Bits
8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 Success
0 0 0 0 0 0 0 1 Port not free
0 0 0 0 0 0 1 0 Port not associated with specified application

0 0 0 0 0 0 1 1 Serialization format not supported

All other values are reserved.

Requested port numbers

This field indicates the destination port numbers that the originator wants to query and shall be encoded as a bitmap of two octets as indicated below.

Port numbers not available

This field indicates the port numbers that are reserved and for which information is not included in the command or response frame. This field shall be encoded as a bitmap of two octets as indicated below.

a) Requested port numbers

The port numbers that are requested are coded in the first and second octet of the Requested port numbers bitmap as follows:

bit 8	7	6	5	4	3	2	bit 1
Port 7	Port 6	Port 5	Port 4	Port 3	Port 2	Port 1	(reserved)	Octet 1

bit 16	15	14	13	12	11	10	bit 9
Port 15	Port 14	Port 13	Port 12	Port 11	Port 10	Port 9	Port 8	Octet 2

A port number is requested, if the corresponding bit is set to "1". All reserved bits shall be set to "0".

b) Port numbers not available

The port numbers that are not available are coded in the first and second octet of the Port numbers not available bitmap as follows:

bit 8	7	6	5	4	3	2	bit 1
Port 7	Port 6	Port 5	Port 4	Port 3	Port 2	Port 1	(reserved)	Octet 1

bit 16	15	14	13	12	11	10	bit 9
Port 15	Port 14	Port 13	Port 12	Port 11	Port 10	Port 9	Port 8	Octet 2

A port number is not available, if the corresponding bit is set to "1". All reserved bits shall be set to "0".

c) Serialization format

The serialization formats that are supported are coded in the first octet of the Serialization Format bitmap as follows:

bit 8	7	6	5	4	3	2	bit 1
(reserved)	(reserved)	(reserved)	(reserved)	(reserved)	XML [5]	JSON [6]	CBOR [7]	Octet 1

A serialization format is supported, if the corresponding bit is set to "1". All reserved bits shall be set to "0".

5.4.2.6.2 Reserve port numbers

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 send a MANAGE_PORT command as shown in figure 5.4.2.6.2-1 by setting the Action field to "Reserve port" and setting the Application ID field to 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 and also negotiate the serialization format used by the application, the originator shall send a MANAGE_PORT command as shown in figure 5.4.2.6.2-2 by setting the Action field to "Reserve port and serialization format" and shall also include all the serialization formats supported by the originator in the Serialization Format field.

Figure 5.4.2.6.2-1: MANAGE_PORT command field format for Action "Reserve port"

Figure 5.4.2.6.2-2: MANAGE_PORT command field format for Action "Reserve port and serialization format"

The receiver shall send a MANAGE_PORT response as shown in figure 5.4.2.6.2-3 and figure 5.4.2.6.2-4, by setting the Action field in response frame to the same value of Action field received in the MANAGE_PORT command frame. If the destination port specified in the MANAGE_PORT command frame is not associated with any application on the receiver, the receiver shall reserve the destination port for use with the application identifier included in the MANAGE_PORT command frame, and shall set the Status field in MANAGE_PORT response frame to "Success", otherwise the Status field is set 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, 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. If the receiver can also support the serialization format indicated by the originator it sets the Serialization Format field in the MANAGE_PORT response frame to the selected serialization format and shall set the Status field in the MANAGE_PORT response frame to "Success".

If the receiver cannot support any of the serialization formats indicated by the originator it 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.

Figure 5.4.2.6.2-3: MANAGE_PORT response field format for Action "Reserve port"

Figure 5.4.2.6.2-4: MANAGE_PORT response field format for Action "Reserve port and serialization format"

If the Status field is set to "Success" in the MANAGE_PORT response frame, the originator shall reserve the Source Port for use with the application specified 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.

5.4.2.6.3 Release port numbers

If the originator wants to release a combination of source and destination port numbers for an application, the originator shall send a MANAGE_PORT command as shown in figure 5.4.2.6.3-1 by setting the Action field to "Release port" and setting the Application ID field to the application currently associated with the combination of the Source Port and Destination Port numbers in the MANAGE_PORT command.

Figure 5.4.2.6.3-1: MANAGE_PORT command field format for Action "Release port"

The receiver shall send a MANAGE_PORT response, by setting the Action field in response frame to "Release port". If the Destination Port specified in the header of the MANAGE_PORT command frame on the receiver is associated with the application specified in the MANAGE_POR command frame, the receiver shall release the Destination Port from use with the application identifier included in the MANAGE_PORT command frame and shall set the Status field in MANAGE_PORT response frame to "Success", otherwise the Status field is set to "Port not associated with specified application".

Figure 5.4.2.6.3-2: MANAGE_PORT response field format for Action "Release port"

If the Status field is set to "Success" in the MANAGE_PORT response frame, the originator shall release the Source Port from use with the application that it is associated with.

5.4.2.6.4 Query port numbers

If the originator 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 send a MANAGE_PORT command as shown in figure 5.4.2.6.4-1 by setting the Action field to "Query port" and indicating the destination port numbers that it intends to query in the optional Requested port numbers. If the originator wants to query the destination port numbers that are reserved and also wants to query the serialization format used by the application, the originator shall send a MANAGE_PORT command by setting the Action field to "Query port and serialization format" and indicating the destination port numbers that it intends to query in the optional Requested port numbers. If the originator intends to query all the port numbers, then it shall not include the Requested port numbers.

Figure 5.4.2.6.4-1: MANAGE_PORT command field format for Action "Query port" or Action "Query port with serialization format"

If the receiver received a MANAGE_PORT command with Action field set to "Query port", the receiver shall send a MANAGE_PORT response as shown in figure 5.4.2.6.4-2, by setting the Action field in response frame to "Query port". If the receiver received a MANAGE_PORT command with Action field set to "Query port and serialization format", the receiver shall send a MANAGE_PORT response as shown in figure 5.4.2.6.4-3, by setting the Action field in response frame to "Query port and serialization format". For each destination port included in the Requested port numbers in the MANAGE_PORT command that is reserved on the receiver and is associated with 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 destination ports entries that are included in the MANAGE_PORT response. For each destination port entry, the receiver shall include the Source Port number that the destination port is paired with and the associated Application ID. 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.

In the case that the entries for all the destination port numbers requested by the originator do not fit in the MANAGE_PORT response, the receiver shall include as many entries for destination port numbers as possible in the MANAGE_PORT response. For all the destination port numbers that are reserved on the receiver, for which the originator has requested information in Requested port numbers in the MANAGE_PORT command and for which information cannot be included in the MANAGE_PORT response, the receiver shall set the corresponding entry in the optional Port numbers not available bitmap. The originator can subsequently query information on these destination port numbers by sending another MANAGE_PORT command and setting Requested port numbers to Port numbers not available in the received MANAGE_PORT response. 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.

NOTE: The entries for all the destination port numbers requested by the originator will fit in the MANAGE_PORT command for cases where the maximum length of the OS specific application identifier is equal-to or less-than 64 octets.

Figure 5.4.2.6.4-2: MANAGE_PORT response field format for Action "Query port"

Figure 5.4.2.6.4-3: MANAGE_PORT response field format for Action "Query port and serialization format"

5.4.2.6.5 Notify port numbers

If the originator wants to notify the receiver of 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 shall send a MANAGE_PORT command as shown in figure 5.4.2.6.5-1 by setting the Action field to "Notify port". If the originator wants to notify the receiver of the source port numbers that are reserved at the originator and also the serialization format used by the application, the originator shall send a MANAGE_PORT command as shown in figure 5.4.2.6.5-2 by setting the Action field to "Notify port and serialization format".

For each source port that is reserved on the originator and is associated with an application, the originator 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 source ports entries that are included in the MANAGE_PORT response. For each source port that is reserved, the originator shall include the Destination Port number that the source port is paired with and the associated Application ID. 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.

In the case that 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 in the MANAGE_PORT command. 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 optional Port numbers not available bitmap. The receiver can subsequently query information on these source port numbers by sending another MANAGE_PORT command by setting the Action field to "Query port" and setting Requested port numbers to Port numbers not available in the received MANAGE_PORT command. 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.

NOTE: The entries for all the source port numbers will fit in the MANAGE_PORT command for cases where the maximum length of the OS specific application identifier is equal-to or less-than 64 octets.

Figure 5.4.2.6.5-1: MANAGE_PORT command field format for Action "Notify port"

Figure 5.4.2.6.5-2: MANAGE_PORT command field format for Action "Notify port and serialization format"

If the receiver supports MANAGE_PORT command with Action field set to "Notify port" or "Notify port and serialization format", there is no response frame sent by the receiver when it receives the above MANAGE_PORT command; otherwise the receiver transmits an ERROR response frame to the originator as described in subclause 5.4.2.4.

5.4.3 Information (I) and Supervisory (S) frames

5.4.3.1 General

The function of the information (I) frame is to transfer, sequentially-numbered frames containing information fields provided by upper layers. This frame shall only be used in acknowledge operation.

Numbered I frames shall also carry supervisory information. A separate S frame is sent when there is no information field to be transferred. Whether an I or S frame is transmitted as a command or as a response is insignificant in the acknowledge operation.

5.4.3.2 Selective Acknowledgement (SACK) command / response

The supervisory frame containing the SACK bitmap shall be used by a receiver to acknowledge a single or multiple I frames. Frames up to and including N(R) ‑ 1, and frames indicated by the SACK bitmap, are deemed to have been received correctly. The format of the SACK control field is shown in figure 5.2.1-1.

In addition to indicating the status of received I frames, the I or S frame containing the SACK bitmap with the A bit set to 1 may be used by the originator to request an acknowledgement from receiver.