Data Service Options for Wideband Spread Spectrum Systems: Radio Link Protocol

Ballot Version Proposed TIA/EIA/PN-3676.2
PN-3676.2 (to be published as TIA/EIA/IS-707.2)

May 30, 1997
Reformatted for HTML, June 2000 (MJF)

Contents

1  INTRODUCTION
    1.1  General Description
    1.2  Terms
    1.3  References
2  GENERAL REQUIREMENTS
    2.1  Required Multiplex Option Support
    2.2  Interface to Multiplex Options
        2.2.1  Primary Traffic
        2.2.2  Secondary Traffic
    2.3  Traffic Channel Frame Priorities
        2.3.1  Non-Transparent RLP
        2.3.2  Transparent RLP Frame Priorities
3  RLP PROCEDURES
    3.1  Non-Transparent RLP Procedures
        3.1.1  Initialization/Reset Procedures
        3.1.2  Data Transfer
        3.1.3  Frame Validity Checks
        3.1.4  Segmentation of Retransmitted Data Frames
    3.2  Transparent RLP Procedures
        3.2.1  Initialization
        3.2.2  Data Transfer
        3.2.3  Frame Validity Checks
    3.3  Traffic Channel Rate Control
        3.3.1  Service Option Negotiation Rate Control Procedures
        3.3.2  Service Negotiation Rate Control Procedures
4  RLP FRAME FORMATS
    4.1  Traffic Channel Frames for Non-Transparent RLP
    4.2  Traffic Channel Frames for Transparent RLP
    4.3  RLP Frame Formats
        4.3.1  RLP Control Frames
        4.3.2  RLP Data Frames
        4.3.3  RLP Idle Frames

1  INTRODUCTION

1.1  General Description

This chapter of TIA/EIA/IS-707 specifies procedures for the Radio Link Protocols supporting the CDMA data services. The Radio Link Protocol specified for the Rate Set 1 multiplex sublayer is a compatible superset of the previous specifications for RLP found in TIA/EIA/IS-99, and in TIA/EIA/IS-657. The Radio Link Protocol specified for the Rate Set 2 multiplex sublayer includes new frame definitions and new segmentation options.

The Radio Link Protocol (RLP) provides an octet stream transport service over forward and reverse traffic channels. RLP is unaware of higher layer framing; it operates on a featureless octet stream, delivering the octets in the order received.

The RLP may be either transparent or non-transparent. Transparent RLP provides maximum throughput transmission of service option data over a CDMA traffic channel, while maintaining bit count integrity over the air interface. The error rate for transparent RLP is that observed on the traffic channel itself. Typically this requires that upper layer data transmission protocols provide error recovery techniques equivalent to those provided in the non-transparent RLP.

Non-transparent RLP substantially reduces the error rate exhibited by CDMA traffic channels. There is no direct relationship between upper layer packets and the underlying traffic channel frames; a large packet may span multiple traffic channel frames, or a single traffic channel frame may contain all or part of several small upper layer packets.

Section 2 below is a general description of RLP that defines its use by any service option for which it is suited. Section 3 defines the RLP procedures for encrypted or non-encrypted applications. Section 4 defines the RLP frame formats.

1.2  Terms

Base Station (BS). A station in the Domestic Public Cellular Radio Telecommunications Service, other than a mobile station, used for communicating with mobile stations. Depending upon the context, the term base station may refer to a cell, a sector within a cell, or other part of the cellular system.

BS. See base station.

BS/MSC. The base station and mobile switching center considered as a single functional entity.

Mobile Station. A station in the Domestic Public Cellular Radio Telecommunications Service intended to be used while in motion or during halts at unspecified points. Mobile stations include portable units (e. g., hand-held personal units) and units installed in vehicles.

MSC. Mobile Switching Center.

RLP. Radio Link Protocol.

1.3  References

ANSI/J-STD-008 Personal Station-Base Station Compatibility Requirements for 1.8 to 2.0 GHz Code Division Multiple Access (CDMA) Personal Communications Systems, Telecommunications Industry Association, Washington, D. C.

TIA/EIA/IS-95-A Mobile Station-Base Station Compatibility Standard for Mode Wideband Spread Spectrum Cellular System, May, 1995.

TSB58 Administration of Parameter Value Assignments for TIA/EIA Wideband Spread Spectrum Standards, December, 1995.

TSB74 Support for 14.4 kbps Data Rate and PCS Interaction for Wideband Spread Spectrum Cellular Systems, December, 1995.

2  GENERAL REQUIREMENTS

2.1  Required Multiplex Option Support

For service options supporting an interface with Multiplex Option 1 or with Multiplex Option 2, non-transparent RLP frames may be transported as primary traffic, or as secondary traffic. Transparent RLP frames shall only be transported as primary traffic.

2.2  Interface to Multiplex Options

Transparent RLP frames are transported as primary traffic, while non-transparent RLP frames can be carried as any traffic type. Section 2.2.1 applies to both transparent and non-transparent RLP frames. Section 2.2.2 applies to non-transparent RLP frames only.

2.2.1  Primary Traffic

When carried as primary traffic, the RLP shall generate and supply exactly one frame containing the service option bits to the multiplex sublayer every 20 milliseconds. The frame shall be one of the types as shown in Table 2.2.1-1. The number of bits supplied to the multiplex sublayer for each type of frame shall also be as shown in Table 2.2.1-1. Unless otherwise commanded by Multiplex Option 1, RLP may supply a Rate 1, Rate 1/2, Rate 1/8 or Blank frame. Unless otherwise commanded by Multiplex Option 2, RLP may supply a Rate 1, Rate 1/2, Rate 1/4, Rate 1/8 or Blank frame. Upon command, the RLP shall generate a Blank frame. A Blank frame contains no bits and is used for burst transmission of signaling traffic (see 6.1.3.3.11 of TSB74) or when the RLP is unable to send a segment of a segmented data frame. Also upon command, the RLP shall generate a non-blank frame with a maximum rate of Rate 1/2.


Table 2.2.1-1. Primary Traffic Frame Types Supplied by the RLP to the Multiplex Sublayer

The multiplex sublayer in the mobile station categorizes every received Traffic Channel frame (see 6.2.2.2 of TSB74), and supplies the frame type and accompanying bits, if any, to the RLP. Table 2.2.1-2 lists the frame types supplied by the multiplex sublayer when RLP is carried as primary traffic by Multiplex Option 1. Although RLP does not generate Rate 1/4 frames, Multiplex Option 1 is not required to recognize this fact. RLP shall declare any received Rate 1/4 frames to be erasures. Table 2.2.1-3 lists the frame types supplied by the multiplex sublayer when RLP is carried as primary traffic by Multiplex Option 2.


Table 2.2.1-2. Primary Traffic Frame Types Supplied by the Multiplex Sublayer to the RLP for Multiplex Option 1


Table 2.2.1-3. Primary Traffic Frame Types Supplied by the Multiplex Sublayer to RLP for Multiplex Option 2

2.2.2  Secondary Traffic

When carried as secondary traffic, RLP shall generate and supply one frame containing the service option bits to the multiplex sublayer every 20 milliseconds. The frame shall be one of the types shown in Table 2.2.2-1. The number of bits supplied to the multiplex sublayer for each type of frame shall also be as shown in Table 2.2.2-1. Upon command, the RLP shall generate a Blank frame. A Blank frame contains no bits and is used for burst transmission of signaling traffic (see 6.1.3.3.11 of TSB74), when primary traffic has priority over secondary traffic and the primary traffic service option sends a Rate 1 frame, or when the RLP is unable to send a segment of a segmented data frame (see 3.1.4).


Table 2.2.2-1. Secondary Traffic Frame Types Supplied by the RLP to the Multiplex Sublayer

The multiplex sublayer in the mobile station categorizes every received Traffic Channel frame (see 6.2.2.2 of TSB74) and supplies the frame type and accompanying bits, if any, to the RLP. Table 2.2.2-2 shows the frame types that may be sent to RLP by the multiplex sublayer when RLP is carried as secondary traffic using Multiplex Option 1. Table 2.2.2-3 shows the frame types that may be sent to RLP by the multiplex sublayer when RLP is carried as secondary traffic using Multiplex Option 2.


Table 2.2.2-2. Secondary Traffic Frame Types Supplied by the Multiplex Sublayer to RLP for Multiplex Option 1


Table 2.2.2-3. Secondary Traffic Frame Types Supplied by the Multiplex Sublayer to RLP for Multiplex Option 2

2.3  Traffic Channel Frame Priorities

2.3.1  Non-Transparent RLP

Each RLP layer shall classify the frames it sends into three priority classes. In order of priority they are, with highest priority first:

  1. RLP control frames
  2. RLP data frames being resent in response to received NAK RLP control frames
  3. RLP data frames being sent for the first time

When the multiplex sublayer indicates that it is ready to send a traffic channel frame, RLP shall select the RLP frame with highest priority among those available for transmission. When RLP is carried as primary traffic, and if no RLP frames in the above three classes are available for transmission, an RLP idle frame (see 4.3.3) shall be sent.

When a service option using RLP is connected as primary traffic, and there is no service option connected as secondary traffic, the mobile station should observe the following priorities in using the traffic channel:

  1. Signaling Traffic
  2. RLP frames in priority class order

When a service option using RLP is connected as secondary traffic, and a service option not using RLP is connected as primary traffic, the mobile station should observe the following priorities in using the traffic channel, if the primary traffic service option permits:

  1. Signaling Traffic

  2. RLP control frames, RLP retransmissions (RLP frames in priority classes 1 and 2), and RLP transmissions due to idle timer expiration (see 3.1.2). If the primary traffic service option permits, the multiplex sublayer should force primary traffic to no more than half rate when these RLP frames iare transmitted.

  3. Primary traffic service option data

  4. New RLP data frames

When data from a service option using RLP over secondary traffic has a lower priority than data from the service option using primary traffic, the blank and burst with secondary traffic frame format (see 6.1.3.3 of TSB74) shall not be used unless the primary traffic service option has no data to send.

When service options using RLP are connected as both primary and secondary traffic, the mobile station should observe the following priorities in using the traffic channel:

  1. Signaling Traffic

  2. RLP control frames and RLP retransmissions (RLP frames in priority classes 1 and 2) pertaining to the service option connected as primary traffic.

  3. RLP control frames, RLP retransmissions, and RLP transmissions (RLP layer priority classes 1 and 2) due to idle timer expiration (see 3.1.2) pertaining to the service option connected as secondary traffic.

  4. New RLP data for the primary traffic service option (RLP frames in priority class 3).

  5. New RLP data for the secondary traffic service option (RLP frames in priority class 3).

2.3.2  Transparent RLP Frame Priorities

When transparent RLP frames are carried as primary traffic, the following priorities should be observed by the mobile station when using the traffic channel.

  1. Signaling Traffic

  2. Transparent RLP Data Frames When a service option using transparent RLP is connected as primary traffic, and no RLP frames are available for transmission, an RLP idle frame (see 4.3.3) shall be sent.

3  RLP PROCEDURES

3.1  Non-Transparent RLP Procedures

Non-transparent RLP provides the capability of both non-encrypted mode and encrypted mode data transport. The encryption capability is selected during RLP Initialization/Reset and is accomplished as a negotiation between the mobile station and the BS/MSC. In addition, a procedure for synchronizing RLP without encryption negotiation is also provided here. The two techniques are compatible with each other and therefore can co-exist in systems where encryption negotiation is supported in the infrastructure equipment, but possibly not in some of the mobile stations attempting access to the system.

3.1.1  Initialization/Reset Procedures

This standard defines two alternate RLP Initialization/Reset procedures. Non-Encrypted Mode initialization/reset shall be used by mobile stations and BS/MSCs that do not support RLP data frame encryption for the desired service. Encrypted Mode initialization/reset procedures shall be used by mobile stations and BS/MSCs to negotiate the use of RLP data frame encryption.

3.1.1.1 Non-Encrypted Mode Initialization and Reset

Non-transparent RLP is established with a bidirectional handshake, after connection of the service option that uses RLP, to synchronize the connection. To establish the RLP without data encryption all control frames used (SYNC, ACK, and SYNC/ACK) shall conform to the Non-Encrypted Mode RLP control frame definitions (see 4.3.1). Accordingly, the control frame names referenced in this section refer only to the Non-Encrypted Mode versions of these frames.

When a traffic type carrying RLP frames is activated, when the traffic type carrying RLP frames is changed, and at other times as specified in this standard or in other service option standards, the RLP layer shall perform the initialization/reset procedure below.

When the RLP layer is initialized or reset, and when a SYNC RLP control frame is received, the RLP layer shall perform the following:

When the RLP layer is initialized or reset, it shall transmit a continuous stream of SYNC RLP control frames (see 4.3.1). When the RLP layer receives a SYNC RLP control frame it shall respond with a SYNC/ACK RLP control frame, and shall continue sending SYNC/ACK RLP control frames until the next valid frame which is not a SYNC RLP control frame is received. When the RLP layer receives a SYNC/ACK RLP control frame it shall respond with an ACK RLP control frame, and shall continue sending ACK RLP control frames until the next valid frame which is not a SYNC/ACK control frame is received. When the RLP layer receives an ACK RLP control frame, it shall send no more SYNC, SYNC/ACK or ACK RLP control frames, and should begin sending RLP data frames.

When RLP frames are carried as primary or secondary traffic, the RLP layer shall store in RLP_DELAYs the number of frames received between the sending of the last SYNC or SYNC/ACK RLP control frame and reception of the first valid frame that is not an ACK or SYNC/ACK RLP control frame. RLP_DELAYs is used in NAK retransmission timing, as described in 3.1.2.1.

3.1.1.2 Encrypted Mode RLP Initialization/Reset

CDMA mobile stations complying with this standard may support authentication (see 6.3.12 of TIA/EIA/IS-95) and may support encryption of RLP data frames using the procedures defined below. RLP data encryption shall be performed whenever cellular authentication procedures have been performed during the establishment of a CDMA Traffic Channel and RLP data encryption is negotiated (see 3.1.1.2.2).

3.1.1.2.1 Extended Data Frame Sequence Numbering

Mobile stations and BS/MSCs supporting RLP data encryption shall support the following extended data frame sequence numbering for RLP data frames.

The RLP layer shall maintain a 30-bit extended sequence number EXT_V(S). EXT_V(S) shall be set to zero when the RLP Layer is initialized following the establishment of a Traffic Channel. For all subsequent initializations/resets of the RLP Layer while the Traffic Channel remains established, the RLP Layer shall perform the following prior to sending an Encrypted Mode SYNC or SYNC/ACK control frame:

For each RLP frame transmitted, the RLP Layer shall set the value of V(S) to the least significant 8 bits of EXT_V(S). EXT_V(S) shall be incremented, following the procedures for incrementing V(S) that are contained in 3.1.2.1 except that EXT_V(S) shall be incremented modulo 230 .

The RLP Layer shall maintain a 30-bit extended sequence number EXT_V(R). When the RLP Layer is initialized or reset, the RLP Layer shall set the least significant 8 bits of EXT_V(R) to zero. The most significant 22 bits of EXT_V(R) shall be set as described in 3.1.1.2.2.1 or 3.1.1.2.2.2 as appropriate.

When V(R) changes (see 3.1.2.1), the RLP Layer shall change EXT_V(R) by the same amount.1

3.1.1.2.2 RLP Data Encryption Negotiation

When authentication is performed during the establishment of a CDMA Traffic Channel, the mobile station and BS/MSC shall set the input parameters of the DataKey_Generation procedure defined in ``Common Cryptographic Algorithms, Revision A. 1'' as follows:

The mobile station and BS/MSC shall then perform the DataKey_Generation procedure. The data encryption key (DataKey) and L table shall not change while the Traffic Channel is established.

Mobile stations and BS/MSCs supporting RLP data encryption shall perform negotiation of RLP data encryption using the procedures in 3.1.1.2.2.1 or 3.1.1.2.2.2, respectively.

When the RLP Layer sends an Encrypted Mode SYNC or SYNC/ACK RLP control frame with the EM field set to '01', the RLP Layer shall set the EXT_SEQ_M field to the most significant 22 bits of the current value of EXT_V(S).

If the EM field is not included in a received RLP control frame, the receiving RLP Layer shall process the message as if EM were included and set to '00'. Throughout the following procedures, the transmitting RLP Layer may send Non-Encrypted Mode RLP control frames whenever the EM field would be set to '00'.

If the BS/MSC requests RLP data encryption, the BS/MSC may deny access to service if authentication procedures (see 6.3.12 of TIA/EIA/IS-95-A) are not performed during Traffic Channel establishment, or if the mobile station indicates by the setting of the EM field that it does not perform RLP data encryption.

3.1.1.2.2.1 Mobile Station Negotiation Procedures

If the mobile station can perform RLP data encryption, the mobile station shall send an Encrypted Mode SYNC RLP control frame to initiate Encrypted Mode Initialization/Reset. The mobile station's RLP Layer shall set the EM field to '01' and shall set the EXT_SEQ_M field to the most significant bits of the mobile station's current value of EXT_V(S).

If the mobile station cannot perform RLP data encryption, the mobile station's RLP Layer shall set the EM field to '00' (or equivalently, send a Non-Encrypted Mode SYNC RLP control frame to initiate Non-Encrypted Mode initialization/reset).

When the mobile station RLP Layer receives an Encrypted Mode SYNC RLP control frame, it shall perform the following:

When the mobile station RLP Layer receives an Encrypted Mode SYNC/ACK RLP control frame, it shall perform the following:

When the mobile station RLP Layer receives an Encrypted Mode ACK RLP control frame, it shall perform the following:

3.1.1.2.2.2 BS/MSC Negotiation Procedures

When the BS/MSC RLP Layer transmits an Encrypted Mode SYNC RLP control frame, it shall perform the following:

When the BS/MSC RLP Layer receives an Encrypted Mode SYNC RLP control frame, it shall perform the following:

When the BS/MSC RLP Layer receives an Encrypted Mode SYNC/ACK RLP control frame, it shall perform the following:

When the BS/MSC RLP Layer receives an Encrypted Mode ACK RLP control frame, it shall perform the following:

3.1.2  Data Transfer

3.1.2.1 Non-Encrypted Data Transfer

When transferring data, non-transparent RLP is a pure NAK-based protocol. That is, the receiver does not acknowledge correct RLP data frames; it only requests the retransmission of RLP data frames that were not received.

All operations on RLP frame sequence numbers shall be carried out in unsigned modulo 256 arithmetic. Comparisons of two RLP frame sequence numbers shall also be modulo 256: for any RLP frame sequence number N, those sequence numbers from (N+1) modulo 256 to (N+127) modulo 256, inclusive, shall be considered greater than N while all sequence numbers from (N-128) modulo 256 to (N-1) modulo 256, inclusive, shall be considered less than N.3

The RLP layer shall maintain an 8-bit sequence number count V(S) for all transmitted RLP data frames (see Figure 3.1.2.1-1). The sequence number field (SEQ) in each new RLP data frame sent and in each RLP idle frame sent shall be set to V(S). V(S) shall be incremented, modulo 256, after formatting each new RLP data frame sent that contains a non-zero number of data octets. V(S) shall not be incremented after an RLP idle frame is sent. New RLP data frames shall not be segmented.


The RLP layer shall maintain two 8-bit sequence number variables for receiving, V(R) and V(N) (see Figure 3.1.2.1-2). V(R) contains the expected value of the RLP frame sequence number field in the next new traffic channel frame to be received. V(N) contains the sequence number of the next needed traffic channel frame not received in sequence, as described below.


The RLP layer shall provide a storage buffer for resequencing of out-of-sequence RLP data frames both on the transmitting and on the receiving side.4 These buffers shall each be able to store no fewer than 128 RLP data frames of the maximum size allowed for the traffic type carrying RLP.

For each received RLP data frame that is valid and contains a non-zero number of data octets, the RLP layer shall compare the sequence number to V(R) and V(N). Criteria for frame validity are given in 3.1.3.

The RLP layer shall also compare the sequence number in each valid received RLP idle frame and NAK RLP control frame to V(R).

On receiving a NAK, the RLP layer shall insert copies of the requested RLP data frame(s) into its output stream. If the NAK includes any sequence number greater than or equal to V(S)5, the RLP layer shall perform the initialization/reset procedures specified in 3.1.1.1 or 3.1.1.2.

If the size of a retransmitted frame is less than or equal to the number of octets available in the traffic channel frame at the time of retransmission, an unsegmented frame (see 4.3.2.1 and 4.3.2.3.2) shall be used. If the size of a retransmitted frame exceeds the number of octets available in the traffic channel frame at the time of retransmission, the RLP layer may segment the frame as specified in 3.1.4.

The RLP layer shall maintain a NAK retransmission timer for each RLP data frame requested in a NAK RLP control frame.

The NAK retransmission timer shall be implemented as a frame counter. The NAK retransmission counter shall be incremented for each valid RLP idle frame and for each valid new RLP data frame (sequence number greater than or equal to V(R)) received on the traffic type where the RLP is carried. When RLP frames are carried as primary traffic, the RLP receiver shall not increment the NAK retransmission counter upon receiving a Blank RLP frame.

When RLP is used with Multiplex Option 1 and is carried as secondary traffic, frame types 2, 3, 4, and 5 (see 6.2.2.2.2 of TIA/EIA/IS-95) are not considered RLP frames and are not counted.

When RLP is used with Multiplex Option 2 and is carried as secondary traffic, frame types 3, 4 and 5 (see 6.2.2.2.1 of TIA/EIA/IS-95) are not considered RLP frames and are not counted.

The NAK retransmission counter shall not be incremented on receiving erasures (as defined in 3.1.3), RLP control frames, Intersegment Fill frames nor old RLP data frames (sequence number less than V(R)). The NAK retransmission counter shall be considered expired when it is incremented to an implementation dependent value greater than RLP_DELAY6.

If any RLP data frame requested has not arrived when its NAK retransmission timer expires, the receiver shall send one or more NAK RLP control frames requesting the retransmission of all unreceived RLP data frames from V(N) upward. RLP data frames requested in a previous NAK RLP control frame whose NAK retransmission timer or NAK abort timer has not expired should not be included in these NAK frames. Each NAK RLP control frame transmitted as the result of a NAK retransmission timer expiration shall be transmitted twice. The RLP layer shall then restart the NAK retransmission timer for the RLP data frames requested.

If any RLP data frame requested has not arrived when its NAK retransmission timer expires for the second time, the receiver shall send one or more NAK RLP control frames requesting the retransmission of all unreceived RLP data frames from V(N) upward. RLP data frames requested in a previous NAK RLP control frame whose NAK retransmission timer or NAK abort timer has not expired should not be included in these NAK frames. Each NAK RLP control frame transmitted as the result of a second NAK retransmission timer expiration shall be transmitted three times. The RLP layer shall then start a NAK abort timer for the RLP data frames requested. The NAK abort timer shall be implemented, and shall be considered expired, according to the same rules as a NAK retransmission timer.

If any RLP data frame requested has not arrived when its NAK abort timer expires, the RLP layer shall set V(N) to the sequence number of the next missing frame, or to V(R) if there are no remaining missing frames. The RLP layer shall then pass any RLP data frames with sequence numbers less than V(N) in order of sequence number to the higher layer. Further recovery is the responsibility of the upper layer protocols.

The RLP layer shall perform the following whenever RLP frames are carried as secondary traffic:

3.1.2.2 Encrypted Data Transfer

3.1.2.2.1 Encryption

When RLP data encryption is negotiated, the Data octets of all transmitted RLP data frames shall be encrypted, using the following procedures.

Encryption mask generation shall be in accordance with the Data_Mask procedure defined in ``Common Cryptographic Algorithms, Revision A. 1.'' When an RLP data frame is transmitted, the RLP layer shall set the input parameters of the Data_Mask procedure, HOOK and LEN (see ``Interface Specification for Common Cryptographic Algorithms, Revision A. 1'') as follows:

The RLP layer shall then execute the Data_Mask procedure. Each octet of the Data part of the RLP data frame shall be combined with the mask by bitwise exclusive-or, combining successive data octets with mask octets.

RLP data frames that are retransmitted shall be encrypted using the same mask as when first transmitted.

If an RLP data frame for retransmission is to be sent as segmented RLP data, the data frame shall be encrypted prior to its segmentation.

3.1.2.2.2 Decryption

For each RLP data frame received, the RLP layer shall form an extended sequence number EXT_SEQ which shall be set equal to EXT_V(R) (see 3.1.1.2.1) minus the difference between V(R) (see 3.1.2.1) and the received sequence number.8 For this calculation, if the received sequence number changes V(R) and EXT_V(R), the new values of V(R) and EXT_V(R) shall be used in the calculation of EXT_SEQ.9

When an encrypted RLP data frame is received, the RLP layer shall set the input parameters of the Data_Mask procedure (see ``Interface Specification for Common Cryptographic Algorithms, Revision A. 1'') as follows:

The RLP layer shall then execute the Data_Mask procedure. Each octet of the Data part of the RLP data frame shall be combined with the mask by bitwise exclusive-or, combining successive data octets with mask octets.

If a retransmitted RLP data frame is received as 2 or more segmented RLP frames, the unsegmented frame shall be reassembled prior to decrypting the data.

3.1.3  Frame Validity Checks

3.1.3.1 Primary Traffic

When RLP frames are carried as primary traffic, the RLP layer shall discard as invalid all traffic channel frames received for which any of the following applies:

  1. The traffic channel frame is classified into category 3, 7, 9, 10 or 12 by Multiplex Option 1 (see 6.2.2.2.1 of TSB74) or into category 26 by Multiplex Option 2 (see 6.2.2.2.2 of TSB74). All such traffic channel frames shall be counted as ``erasures10'' by RLP.
  2. For RLP control frames, the FCS field does not check; for eighth and sixteenth rate intersegment fill frames and eighth-rate RLP idle frames, the FCS field is not the correct value for the value of the SEQ field. All such traffic channel frames shall be counted as ``erasures'' by RLP.
  3. RLP frame TYPE field value is not one of the values defined in 4.3.
  4. RLP frame LEN field value is not within the range allowed in 4.3.
  5. RLP frame CTL field value is not a value as defined in 4.3.
  6. For Rate 1/8 and Rate 1/16 frames only, the received RLP frame sequence number is not within the range from V(R) to (V(R)+ E) modulo 256, inclusive, where E is the number of consecutive erasures (see (1) and (2) above) preceding the current frame, and V(R) is as defined in 3.1.2.1.
  7. For Rate 1/8 frames only, the frame is not identical in contents to the preceding frame.

All other traffic channel frames shall be considered valid.

If three consecutive identical Rate 1/8 frames arrive with a sequence number that is out of the acceptable range, as defined in (6) above, then:

The RLP layer shall maintain a count E of the consecutive frames classified as ``erasures,'' as defined in (1) above. If the consecutive erasure count E exceeds 127, the RLP layer shall perform the initialization/reset procedure specified in 3.1.1.

3.1.3.2 Secondary Traffic

When RLP frames are carried as secondary traffic, the RLP layer shall discard as invalid all traffic channel frames received for which any of the following applies:

  1. The traffic channel frame is classified into category 9 or 10 by Multiplex Option 1 or into category 26 by Multiplex Option 2 (see 6.2.2.2 of TSB74). All such frames shall be counted as ``erasures'' by RLP. All other frame categories that do not include secondary traffic are ignored by RLP; only those listed here shall be classified as erasures.
  2. For RLP control frames, idle frames and Rate 1/8 and Rate 1/16 intersegment fill frames, the FCS field does not check.
  3. RLP frame TYPE field value is not one of the values defined in 4.3.
  4. RLP frame LEN field value is not within the range allowed in 4.3.
  5. RLP frame CTL field value is not a value as defined in 4.3.

All other traffic channel frames shall be considered valid, and shall be processed by RLP if they contain secondary traffic data.

The RLP layer shall maintain a count E of the consecutive frames classified as ``erasures,'' as defined in (1) above.

If the consecutive erasure count E exceeds 127, the RLP layer shall perform the initialization/reset procedure specified in 3.1.1.

3.1.4  Segmentation of Retransmitted Data Frames

The following procedures apply to the segmentation and reassembly of RLP data frames. Segmentation may be necessary when a retransmitted frame size exceeds the number of octets available at the time the retransmission occurs.

The RLP layer procedures below assure that no more than three data bearing segments are needed to transmit an RLP frame by requiring all but the last segment to use at least a Rate 3/8 frame.11

A retransmitted RLP data frame may be sent in one, two or three segments. If the retransmitted frame is sent in a single segment, an unsegmented frame (see 4.3.2.1 and 4.3.2.3.2) is used. If the retransmitted RLP data frame size exceeds the number of octets available at the time the retransmission occurs, the RLP layer should segment the frame. With the exception of intersegment fill frames, all RLP segmented frames except the last segmented frame shall be sent using Rate 3/8 or larger RLP frames.

When Rate Set 2 is used, an Intersegment Fill frame (see 4.3.2.2 and 4.3.2.2.1) can be sent by the BS/MSC. Mobile stations complying with this standard shall not transmit intersegment fill frames on the reverse link. When the intersegment fill frame is used the sequence number of an Intersegment Fill frame shall be set equal to the sequence number of the RLP data frame being retransmitted.

The RLP layer segments the frame using the following procedure:

The RLP layer shall begin frame reassembly on receipt of the first segment of a segmented RLP data frame. When RLP is carried with Multiplex Option 2, if an Intersegment Fill frame is received, the RLP layer shall discard it. When the last segment of the RLP data frame is received, the RLP layer shall process the RLP data frame in the same manner as if it had been unsegmented (see 4.3.2.1).

The RLP layer shall discard, without further processing, any segmented RLP data frame that is received under any of the following conditions:

3.2  Transparent RLP Procedures

3.2.1  Initialization

Transparent RLP maintains two state variables, V(S), and V(R) (see 3.2.2). When a service option using transparent RLP is connected, the transparent RLP layer shall perform the following:

3.2.2  Data Transfer

Transparent RLP does not provide any retransmission of erased frames. It is the responsibility of the upper layers to provide further synchronization and error recovery when Transparent RLP is used.

Transparent RLP shall maintain two eight-bit sequence number variables, V(S) (for transmitting) and V(R) (for receiving). See 3.2.1 for initialization procedures for these state variables.

If Transparent RLP has no data to send, Transparent RLP generates and transmits an idle RLP frame (see 4.3.3). When an idle RLP frame is sent, transparent RLP shall set the SEQ field to the current value of V(S). V(S) shall not be incremented when Transparent RLP sends an idle RLP frame. When an idle RLP frame is received by Transparent RLP, Transparent RLP may discard it.

When a transparent RLP frame is to be transmitted the RLP transmitter shall perform the following:

When a transparent RLP data frame is received the transparent RLP receiver shall perform the following:

When the transparent RLP receives an idle frame from the multiplex sublayer, the transparent RLP receiver shall discard the frame.

3.2.3  Frame Validity Checks

Transparent RLP shall discard as invalid all traffic channel frames received which are classified into category 9 or 10 by Multiplex Option 1 (see 6.2.2.2 of TIA/EIA/IS-95).

Transparent RLP sublayer shall discard as invalid all traffic channel frames received which are classified into category 26 by Multiplex Option 2 (see 6.2.2.2 of TIA/EIA/IS-95).

3.3  Traffic Channel Rate Control

The following requirements for traffic channel rate control shall apply to mobile stations having a single connected service option. Traffic channel rate control for mobile stations having multiple connected service options is for further study.

3.3.1  Service Option Negotiation Rate Control Procedures

The BS/MSC may send a Service Option Control Order to the mobile station on the Forward Traffic Channel (see 7.7.4 of TIA/EIA/IS-95-A). The mobile station shall not send Service Option Control Orders for the purpose of rate control to the BS/MSC.

If the mobile station receives a Service Option Control Order having an ORDQ field in which the 3 MSBs have values given in Table 3.3.1-1, then the mobile station shall generate the fraction P of those new traffic channel frames normally generated as full-rate frames at either full rate (Rate 1) or half rate (Rate 1/2) as specified by the corresponding line in the table. While the traffic channel is active the mobile station shall continue to use these fractions until the mobile station receives a Service Option Control Order that specifies different fractions.

Whenever a traffic channel first becomes active, the mobile station shall set the fraction P to 1.


Table 3.3.1-1. Fraction of Frames at Rate 1 and Rate 1/2 with Rate Reduction

The mobile station may use the following procedure to perform this rate reduction. Sequences of N frames are formed as shown in Table 3.3.1-2. The first L traffic channel frames in this sequence are allowed to be at Rate 1, the next N-L frames are forced to be Rate 1/2. Whenever the RLP layer has no more octets to send than fit in a Rate 1/2 RLP data frame, a Rate 1/2 RLP data frame shall be sent, and the sequence shall be reset. This ensures that the first traffic channel frame in a burst of data will be at Rate 1, unless ORDQ equals '100XXXXX' or the RLP layer has been commanded by the multiplex sublayer to generate other than a Rate 1 frame.


Table 3.3.1-2. Sequence Parameters for Rate Reduction

3.3.2  Service Negotiation Rate Control Procedures

If service negotiation is used, the BS/MSC may send a Service Option Control Message to the mobile station on the Forward Traffic Channel (see 7.7.3.3 of TIA/EIA/TSB-74). The mobile station shall not send a Service Option Control Message to the BS/MSC.

3.3.2.1 Mobile Station Requirements

The mobile station shall support one pending rate control Service Option Control Message for the service option.

If the mobile station receives a Service Option Control Message for the service option with FIELD_TYPE set to '000', then at the action time associated with the message, the mobile station shall process the message as follows:

The service option may use the following procedure to perform rate reduction. Sequences of N frames are formed as shown in Table 3.3.2.1-1 are allowed to be at Rate 1, the next N-L frames are forced to be Rate 1/2. Whenever the RLP layer has no more octets to send than fit in a Rate 1/2 RLP data frame, a Rate 1/2 RLP data frame shall be sent, and the sequence shall be reset. This ensures that the first Traffic Channel frame in a burst of data will be at Rate 1, unless RATE_REDUC equals '100' or the RLP layer has been commanded by the multiplex sublayer to generate other than a Rate 1 frame.


Table 3.3.2.1-1. Sequence Parameters for Rate Reduction

3.3.2.2 BS/MSC Requirements

The BS/MSC may send a Service Option Control Message to the mobile station for Traffic Channel rate control. If the BS/MSC sends a Service Option Control Message for Traffic Channel rate control, the BS/MSC shall include the type-specific fields shown in Table 3.3.2.2-1.


Table 3.3.2.2-1. Service Option Control Message Type-Specific Fields for Traffic Channel Rate Control

RATE_REDUC - Rate reduction.

The BS/MSC shall set this field to the RATE_REDUC value from Table 3.3.2.2-2 corresponding to the rate reduction that the mobile station is to perform.

RESERVED - Reserved bits.

The BS/MSC shall set this field to '00'.

FIELD_TYPE - Type-specific field designator.

The BS/MSC shall set this field to '000'.


Table 3.3.2.2-2. Fraction of Frames at Rate 1 and Rate 1/2 with Rate Reduction 9

4  RLP FRAME FORMATS

4.1  Traffic Channel Frames for Non-Transparent RLP

Non-transparent RLP shall send and receive traffic channel frames in accordance with the requirements of IS-95 Multiplex Options 1 and 2.

Non-transparent RLP frames can be transmitted as primary traffic or as secondary traffic. Service options may support any subset of the available traffic types and RLP frame types to carry non-transparent RLP.

Mobile stations supporting multiple connected service options may support independent instances of non-transparent RLP for each service option, but each traffic type shall carry only a single instance of non-transparent RLP. RLP data frames sent on one traffic type shall not be retransmitted on another traffic type.

Non-transparent RLP frames shall not be sent on the Access and Paging Channels. The frame formats defined in 4.3.1 through 4.3.3 can be carried by the following Multiplex Option 1 frames (see 6.1.3.3.11 and 7.1.3.5.11 of TSB74).

The frame formats defined in 4.3.1 through 4.3.3 can be carried by the following Multiplex Option 2 frame formats (see 6.1.3.3.12 and 7.1.3.5.12 of TSB74):

For full rate primary traffic only, two special frame formats are defined in 4.3.2.3. The information field of the first format corresponds to an RLP control or data frame as defined in 4.3.1 and 4.3.2 respectively. The second frame format contains a sequence number and user data only and allows maximum throughput.

4.2  Traffic Channel Frames for Transparent RLP

Transparent RLP shall send and receive traffic channel frames in accordance with the requirements of IS-95 Multiplex Options 1 and 2.

Transparent RLP frames can be transmitted as primary traffic only. Service options may support any subset of the RLP data frame types to carry transparent RLP.

Mobile stations supporting multiple connected service options may support a single instance of Transparent RLP. Transparent RLP frames shall not be sent on the Access and Paging Channels.

The frame formats defined in 4.3.2 below can be carried by the following Multiplex Option 1 frames (see 6.1.3.3.11 and 7.1.3.5.11 of TSB74):

The frame formats defined in 4.3.2 below can be carried by the following Multiplex Option 2 frames (see 6.1.3.3.12 and 7.1.3.5.12 of TSB74):

For full rate primary traffic only, transparent RLP may use the Full Rate Format B frame, as defined in 4.3.2.3.2.

4.3  RLP Frame Formats

4.3.1  RLP Control Frames

RLP control frames are distinguished by the CTL field. RLP control frames are not themselves sequence numbered, but contain the next data sequence number, in order that erased RLP data frames may be quickly detected. The sequence number is not incremented after an RLP control frame.

Certain RLP control frames (specifically the NAK message) may refer to the sequence numbers of other RLP data frames.


SEQ -RLP data frame sequence number. See 3.1.2.
CTL -RLP frame type. For RLP control frames, the CTL field is defined as follows:

'1100 0000' -NAK (negative acknowledgment). Requests retransmission of RLP data frames numbered FIRST through LAST, inclusive.

'1101 0000' -Non-Encrypted Mode SYNC. Requests return of an RLP control frame with the ACK bit set.

'1101 0011' -Encrypted Mode SYNC. Requests return of an RLP control frame with the ACK bit set.

'1110 0000' -Non-Encrypted Mode ACK. Acknowledges receipt of an RLP control frame with the SYNC bit set.

'1110 0011' -Encrypted Mode ACK. Acknowledges receipt of an RLP control frame with the SYNC bit set.

'1111 0000' -Non-Encrypted Mode SYNC/ACK. Indicates both SYNC and ACK.

'1111 0011' -Encrypted Mode SYNC/ACK. Indicates both SYNC and ACK.

FIRST -For NAK RLP control frames, the FIRST field shall contain the sequence number of the first RLP data frame for which retransmission is requested. For all other RLP control frame types, this field shall contain 0x00.

LAST -For NAK RLP control frames, the LAST field shall contain the sequence number of the last RLP data frame for which retransmission is requested. For all other RLP control frame types, this field shall contain 0x00.

EM -Encryption Mode. This field shall be included in Encrypted Mode SYNC, SYNC/ACK and ACK RLP control frames. This field shall not be included in NAK RLP control frames or in Non-Encrypted mode RLP control frames.
'00' (Default) Requests or Acknowledges no RLP data frame encryption (not supported or inactive).

'01' Requests or Acknowledges RLP data frame encryption capability.

EXT_SEQ_M -This field shall be included in Encrypted Mode SYNC, SYNC/ACK and ACK RLP control frames. This field shall not be included in NAK RLP control frames.

When the EM field is set to '01', this field shall carry the most significant bits of the extended data frame sequence number. Otherwise, this field shall be set to all zeros.

When included, contents of this field shall be set to the 22 most significant bits of EXT_V(S) (see 3.1.1.2.2).

FCS -Frame Check Sequence. The contents shall be as generated by the 16-bit FCS polynomial specified in 3.1 of RFC 1662. The FCS shall cover the SEQ, CTL, FIRST, LAST, EM (if included), and EXT_SEQ_M (if included) fields.

Padding -Padding bits. As required to fill the remainder of the frame. These bits shall be set to '0'.

4.3.2  RLP Data Frames

4.3.2.1 Unsegmented RLP Data Frames

Unsegmented RLP data frames carry a variable number of data octets, using a length field to indicate the number of octets.


SEQ -RLP data frame sequence number. See 3.1.2.

CTL -RLP frame type. For a frame carrying unsegmented data the CTL field shall be set to '0'15

LEN -Data length. May be any value in the range from 0 to the 1 maximum allowable for the RLP frame. Maximum values of LEN (MAX_LEN) are as given in Table 4.3.2.1-1. When LEN is zero, the RLP frame is treated as an RLP idle frame, and the sequence number is not advanced.

Data -Data octets.

Padding -Padding bits. As required to fill the remainder of the frame. These bits shall be set to '0'.


Table 4.3.2.1-1. Values of the Maximum Allowable Data Length (MAX_LEN) 10

4.3.2.2 Segmented RLP Data Frames

Segmented RLP data frames carry a variable number of data octets, using a length field to indicate the number of octets. This type of data frame shall be used only to carry retransmitted RLP data frames (see 3.1.4).


SEQ -RLP data frame sequence number. See 3.1.2.

CTL -RLP frame type. For segmented RLP data frames, the CTL field is defined as follows:

'1000' -First Segment. Contains the first LEN octets of the segmented RLP data frame.

'1001' -Second Segment. Contains the next LEN octets of the segmented RLP data frame.

'1010' -Last Segment. Contains the last LEN octets of the segmented RLP data frame.

'1011' -RLP Intersegment Fill Frame. When Multiplex Option 2 is used, RLP Intersegment Fill Frames can be sent before or between segmented RLP data frames (see 3.1.4). RLP Intersegment Fill Frames are not used for Multiplex Option 1.

LEN -Data length. When CTL is set to '' 1000', '1001', or '1010', the LEN field may be any value in the range from 1 to the maximum allowable for the RLP frame, or 15, whichever is less. Values of the maximum allowable data length (MAX_LEN) are as given in Table 4.3.2.1-1. When CTL is set to '1011' the LEN field shall not be included.

Data -Data octets. When CTL is set to '1000', '1001', or '1010', this field shall carry LEN Data octets. When CTL is set to '1011' the Data field shall not be included

Padding -Padding bits. As required to fill the remainder of the frame. These bits shall be set to '0'.

4.3.2.2.1 Rate 1/8 and Rate 1/16 Intersegment Fill Frames

For Multiplex Option 2, Rate 1/8 primary traffic RLP frames and Rate 1/16 secondary traffic RLP frames may be Intersegment Fill frames.


SEQ -RLP data frame sequence number. See 3.1.4.

FCS -Frame Check Sequence. This field is identical to the FCS field of an RLP idle frame with matching SEQ field. See 4.3.3.

ISF -Intersegment Fill frame indicator. The value '1111' indicates an Intersegment Fill frame.

4.3.2.3 Primary Traffic

For RLP frames carried on full rate primary traffic frames, two special frame formats described in 4.3.2.3.1 and 4.3.2.3.2 shall be used. For RLP frames carried on half-rate or quarter rate frames, RLP data frames or RLP control frames, as defined in 4.3.2 and 4.3.2.1, apply directly.

4.3.2.3.1 Full Rate Format A

IS-95 full rate primary traffic frames of format A can carry either RLP data frames or RLP control frames, as defined in 4.3.1 and 4.3.2.

For Multiplex Option 1, full rate format A frames are defined as follows:


Information -RLP control or data frame. Formatted according to the RLP control and data frames described in 4.3.1 and 4.3.2.1.

TYPE -Frame type. The TYPE field shall be set to '001'.

For Multiplex Option 2, full rate format A frames are defined as follows:


Information -RLP control or data frame. Formatted according to the RLP control and data frames described in 4.3.1 and 4.3.2.1.

TYPE -Frame type. The TYPE field shall be set to '01'.

4.3.2.3.2 Full Rate Format B

For Multiplex Option 1, format B carries 20 octets of data, as follows:


SEQ -Frame sequence number. See 3.1.2.

Data -Data octets. This field shall contain 20 octets of data. TYPE -Frame type. The TYPE field shall be set to '010'.

For Multiplex Option 2, format B carries 32 octets of data, as follows:


SEQ -Frame sequence number. See 3.1.2.
Data -Data octets. This field shall contain 32 octets of data.
TYPE -Frame type. The TYPE field shall be set to '10'.

4.3.3  RLP Idle Frames

For Multiplex Option 1, Rate 1/8 RLP frames are RLP idle frames. For Multiplex Option 2, Rate 1/8 primary traffic RLP frames and Rate 1/16 secondary traffic RLP frames may be RLP idle frames. Higher rate RLP data frames with zero length (LEN = 0) (see 4.3.2.1) are also RLP idle frames, and may be sent as an alternative.


SEQ -RLP frame sequence number. This field is set to the current value of V(S) (see 3.1.2.1 and 3.2.2).

FCS -Frame Check Sequence based on a modified Nordstrom-Robinson code.

Let the sequence number to be coded be denoted as
(X7 X6 X5 X4 X3 X2 X1 X0)

Let the FCS be denoted as
(Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0)

The FCS is generated as follows:


Y0 = X7 X6 X0 X1 X3 (X0 X4)·( X1 X2 X3 X5)(X1 X2)·(X3 X5)

Where denotes modulo-2 addition. Code bits Y1 through Y6 are found by cyclically shifting X0 through X6 . In other words, X(i+j)mod 7 is substituted for Xi in the generating equation for Yj. Y7 is a parity bit over the previous 15 bits. The final step in generating the FCS is to complement the last three bits. A table specifying the code is provided in Table 4.3.3-1.

Pad -Padding bits. As required to fill the remainder of the frame. These bits shall be set to '0'.

Table 4.3.3-1 presents the modified Nordstrom-Robinson code used to protect Rate 1/8 and Rate 1/16 RLP idle frames. In Table 4.3.3-1, the most significant byte in a word is the SEQ value to be protected and the least significant byte is the FCS. All numbers are hexadecimal.

Table 4.3.3-1. Modified Nordstrom-Robinson Code 2



Footnotes:

1That is, if the old value of V(R) is A and the new value of V(R) is B, EXT_V(R) is incremented by (256+ B-A) modulo 256. All arithmetic operations on EXT_V(R) are modulo 230.

2It is anticipated that future revisions of PPP, IP and other protocols may include encryption.

3Note that (N-1) modulo 256 is equal to (N+255) modulo 256, and (N-128) modulo 256 is equal to (N+128) modulo 256.

4ie. two such buffers are required in a mobile station.

5This would indicate that the NAK process has fallen behind the sequence numbering by more than 128 frames.

6It is recommended that a guard interval of five frames be added to the retransmission timeout to account for buffering within the TIA/EIA/IS-95-A mobile or base station and for segmentation of retransmitted frames.

7When RLP is carried as secondary traffic, an RLP idle frame is an RLP data frame with zero length (see 4.3.2.1).

8That is, if the received sequence number is N, EXT_SEQs is set to EXT_V(R)-((256+ V(R)-N) modulo 256).

9This ensures that the received sequence number is never less than V(R).

10The ``erasures'' defined here serve to inhibit incrementing of the NAK retransmission timer. They are not to be confused with TIA/EIA/IS-95 frame erasures.

11For Multiplex Option 1, the smallest available frame that carries data is Rate 1/2, which is larger than Rate 3/8.

12RLP would be carried as both primary and secondary traffic simultaneously if there are two service options active (one using primary traffic and the other using secondary traffic), each with its own instance of RLP.

13RLP would be carried as both primary and secondary traffic simultaneously if there are two service options active (one using primary traffic and the other using secondary traffic), each with its own instance of RLP.

14With the exception of the last segmented frame, Rate 1/4 RLP frames may not carry segmented RLP data frames(see 3.1.4).

15Note that the most significant bit of the CTL field of a control frame and a segmented data frame is always set to '1'.


File translated from TEX by TTH, version 2.70.
On 24 Jul 2000, 14:53.