6.2.3.6 Encryption of MAC PDUs

When transmitting a MAC PDU on a connection that is mapped to an SA, the sender shall perform encryption and data authentication of the MAC PDU payload as specified by that SA. When receiving a MAC PDU on a connection mapped to an SA, the receiver shall perform decryption and data authentication of the MAC PDU payload, as specified by that SA.

NOTE—Data authentication is not currently defined.

The Generic MAC Header shall not be encrypted. The Header contains all the Encryption information (Encryption Control Field, Encryption Key Sequence Field, and CID) needed to decrypt a Payload at the receiving station. This is illustrated in Figure 31.

Encrypted portion of the MAC PDU

Figure 31—MAC PDU encryption

Two bits of a MAC Header contain a key sequence number. Note that the keying material associated with an SA has a limited lifetime, and the BS periodically refreshes an SA’s keying material. The BS manages a 2-bit key sequence number independently for each SA and distributes this key sequence number along with the SA’s keying material to the client SS. The BS increments the key sequence number with each new generation of keying material. The MAC Header includes this sequence number to identify the specific generation of that SA keying material being used to encrypt the attached payload. Being a 2-bit quantity, the sequence number wraps around to 0 when it reaches 3.

Comparing a received MAC PDU’s key sequence number with what it believes to be the “current” key sequence number, an SS or BS can easily recognize a loss of key synchronization with its peer. An SS shall maintain the two most recent generations of keying material for each SA. Keeping on hand the two most recent key generations is necessary for maintaining uninterrupted service during an SA’s key transition.

Encryption of the payload is indicated by the Encryption Control (EC) bit field. A value of 1 indicates the payload is encrypted and the EKS field contains meaningful data. A value of 0 indicates the payload is not encrypted. Any unencrypted MAC PDU received on a connection mapped to an SA requiring encryption shall be discarded.

6.2.4 ARQ mechanism

Automatic repeat request (ARQ) shall not be used with the PHY specification defined in 8.2.

6.2.5 Uplink scheduling service

Scheduling services are designed to improve the efficiency of the poll/grant process. By specifying a scheduling service and its associated QoS parameters, the BS can anticipate the throughput and latency needs of the uplink traffic and provide polls and/or grants at the appropriate times.

The basic services, as summarized in Table 58, are Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), Non-Real-Time Polling Service (nrtPS) and Best Effort (BE) service. Each service is tailored

to a specific type of data flow. The following subclauses define the basic uplink service flow scheduling services and list the QoS parameters associated with each service. A detailed description of each QoS parameter is provided in 11.4.8.

Table 58—Scheduling services and usage rules

6.2.5.1 Unsolicited Grant Service

The Unsolicited Grant Service (UGS) is designed to support real-time service flows that generate fixed size data packets on a periodic basis, such as T1/E1 and Voice over IP without silence suppression. The service offers fixed size grants on a real-time periodic basis, which eliminate the overhead and latency of SS requests and assure that grants are available to meet the flow’s real-time needs. The BS shall provide fixed size Data Grant Burst Types at periodic intervals to the service flow. In order for this service to work correctly, the Request/Transmission Policy (see 11.4.8.12) setting shall be such that the SS is prohibited from using any contention request opportunities, and the BS shall not provide any unicast request opportunities for that connection. This results in the SS only using unsolicited Data Grant Burst Types for uplink transmission on that connection. All other bits of the Request/Transmission Policy are irrelevant to the fundamental operation of this scheduling service and should be set according to network policy. The UGS shall be specified using the following parameters: the Unsolicited Grant Size, the Nominal Grant interval, the Tolerated Grant Jitter, and the Request/Transmission Policy.

The Grant Management subheader (6.2.2.2.2) is used to pass status information from the SS to the BS regarding the state of the UGS service flow. The most significant bit of the Grant Management field is the Slip Indicator (SI) bit. The SS shall set this flag once it detects that this service flow has exceeded its transmit queue depth. Once the SS detects that the service flow’s transmit queue is back within limits, it shall clear the SI flag. The flag allows the BS to provide for long term compensation for conditions, such as lost maps or clock rate mismatches, by issuing additional grants. The poll-me bit (6.2.6.4.3) may be used to request to be polled for a different, non-UGS connection.

The BS shall not allocate more bandwidth than the Maximum Sustained Traffic Rate parameter of the Active QoS Parameter Set, excluding the case when the SI bit of the Grant Management field is set. In this case, the BS may grant up to 1% additional bandwidth for clock rate mismatch compensation.

6.2.5.2 Real-Time Polling Service

The Real-Time Polling Service (rtPS) is designed to support real-time service flows that generate variable size data packets on a periodic basis, such as MPEG video. The service offers real-time, periodic, unicast request opportunities, which meet the flow’s real-time needs and allow the SS to specify the size of the desired grant. This service requires more request overhead than UGS, but supports variable grant sizes for optimum data transport efficiency.