Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in
6. MAC common part sublayer
6.3 Data/Control plane
6.3.2 MAC PDU formats .1 MAC header formats.1 MAC header formats
6.3.2.3 MAC Management messages [Change Table 14 as indicated:][Change Table 14 as indicated:]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
6.3.2.3 MAC Management messages
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
20 Reserved
21 MCA-REQ Multicast Assignment Request Primary Management
22 MCA-RSP Multicast Assignment Response Primary Management
23 DBPC-REQ Downlink Burst Profile Change Request Basic 24 DBPC-RSP Downlink Burst Profile Change Response Basic
25 RES-CMD Reset Command Basic
26 SBC-REQ SS Basic Capability Request Basic
27 SBC-RSP SS Basic Capability Response Basic
28 CLK-CMP SS network clock comparison Broadcast
29 DREG-CMD De/Re-register Command Basic
30 DSX-RVD DSx Received Message Primary Management
31 TFTP-CPLT Config File TFTP Complete Message Primary Management 32 TFTP-RSP Config File TFTP Complete Response Primary Management
33 ARQ-Feedback Standalone ARQ Feedback Basic
34 ARQ-Discard ARQ Discard message Basic
35 ARQ-Reset ARQ Reset message Basic
36 REP-REQ Channel measurement Report Request Basic
37 REP-RSP Channel measurement Report Response Basic
38 FPC Fast Power Control Broadcast
39 MSH-NCFG Mesh Network Configuration Broadcast
40 MSH-NENT Mesh Network Entry Basic
41 MSH-DSCH Mesh Distributed Schedule Broadcast
42 MSH-CSCH Mesh Centralized Schedule Broadcast
43 MSH-CSCF Mesh Centralized Schedule Configuration Broadcast
44 AAS-FBCK-REQ AAS Feedback Request Basic
45 AAS-FBCK-RSP AAS Feedback Response Basic
46 AAS_Beam_Select AAS Beam Select message Basic
47 AAS_BEAM_REQ AAS Beam Request message Basic
48 AAS_BEAM_RSP AAS Beam Response message Basic
49 DREG-REQ SS De-registration message Basic
50— 255
reserved
50 MOB_SLP-REQ sleep request message basic
51 MOB_SLP-RSP sleep response message basic
Type Message name Message description Connection
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
[Change the text below Table 14 as indicated:]
In general, the PKM-RSP message is carried on the Primary Management connection. However, in order to send the PKM-RSP message in key push mode to MS for multicast service or broadcast service, it may be carried on the Broadcast connection.
During the adaptive antenna system (AAS) portion of the frame the DL-MAP, UL-MAP, DCD, UCD, MOB_NBR-ADV, MOB_TRF-IND, MOB_PAG-ADV and CLK-MAP messages may be sent using the basic CID.
6.3.2.3.2 Downlink map (DL-MAP) message [Insert the following text at the end of the 6.3.2.3.2:]
The UL-MAP message (when present) shall be always transmitted in the first PDU on the burst described by the first DL-MAP_IE of the DL-MAP (or, in the case of the OFDM PHY mode, of the DLFP).
6.3.2.3.5 Ranging Request (RNG-REQ) message
[Change the text in 6.3.2.3.5 (beginning with the sentence shown) as indicated.]
52 MOB_TRF-IND traffic indication message broadcast
53 MOB_NBR-ADV neighbor advertisement message broadcast,
primary management 54 MOB_SCN-REQ scanning interval allocation request basic
55 MOB_SCN-RSP scanning interval allocation response basic
56 MOB_BSHO-REQ BS HO request message basic
57 MOB_MSHO-REQ MS HO request message basic
58 MOB_BSHO-RSP BS HO response message basic
59 MOB_HO-IND HO indication message basic
60 MOB_SCN-REP Scanning result report message primary management
61 MOB_PAG-ADV BS broadcast paging message broadcast
62 MBS_MAP MBS MAP message
63 PMC_REQ Power control mode change request message Basic 64 PMC_RSP Power control mode change response message Basic 65 PRC-LT-CTRL Setup/Tear-down of long term MIMO precoding Basic
66 MOB_ASC-REP Association result report message primary management
67-255 reserved
aFor subscribers and base stations that support PKMv2, PKM-RSP is sometimes transmitted on the broadcast connection.
Table 14 MAC Management messages (continued)
Type Message name Message description Connection
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
TLV message elements shall only be included in RNG-REQ messages of adequate UL bandwidth. In OFDMA, when the MS transmits the handover CDMA ranging code, BS shall provide for initial UL band-width allocation of size at least sufficient for transmission of RNG-REQ message with MS MAC address TLV and Grant Management subheader. If required TLV message elements cannot be accommodated in the UL bandwidth of a current RNG-REQ message, after the MS obtains a Basic CID from the BS, the MS shall make UL BW request of sufficient size to conduct additional RNG-REQ including all required message ele-ments, at the first available opportunity.
The following parameters shall be included in the RNG-REQ message when the SS is attempting to join the networkinitial entry to the network:
Requested Downlink Burst Profile SS MAC Address
The following parameters shall be included in the RNG-REQ message when transmitted during SS initial entry to the network. The parameter shall be sent on the SS’s Basic connection or for OFDMA on the initial ranging connection:
MAC Version (11.1.3)
The following parameters may be included in the REQ message after the SS has received an RNG-RSP addressed to the SS:
Requested Downlink Burst Profile Ranging Anomalies
The following parameter may be included in the RNG-REQ message:
AAS broadcast capability
The following parameters may be included in the RNG-REQ message when the MS is attempting to perform re-entry, association or handover:
Requested Downlink Burst Profile
The following parameters shall be included in the RNG-REQ message when the MS is attempting to per-form re-entry, association or handover:
Serving BSID
The BSID of the BS to which the MS is currently connected (has completed the registra-tion cycle and is in Normal Operaregistra-tion). The serving BSID shall not be included if the aging timer is timed-out (serving BSID AGINGTIMER, see Table 264a). Inclusion of serving BSID in the RNG-REQ message signals to the target BS that the MS is currently connected to the network through the serving BS and is per-forming association or is in the process of handover network re-entry.
The following TLV parameter shall be included in the RNG-REQ message when the MS is attempting to perform re-entry, handover, or Location Update:
Ranging Purpose Indication
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
Presence of item in message indicates MS action as follows:
If bit #0 is set to 1, in combination with serving BS ID BSID indicates the MS is currently attempting to HO; or in combination with Paging Controller ID the MS is attempting Network Re-entry from Idle Mode to the BS.
If bit #1 is set to 1, indicates MS action of Idle Mode Location Update Process
The following TLV parameter shall be included in the RNG-REQ message when the MS is attempting to perform re-entry:
Paging Controller ID
The Paging Controller ID is a logical network identifier for the serving BS or other net-work entity retaining MS service and operational information and/or administering paging activity for the MS while in Idle Mode.
The following TLV parameter may be included in RNG-REQ message when a MS is performing initial ranging to the selected target BS:
HO_ID
Optional ID assigned for use in initial ranging to the target BS during HO once the BS is selected as the target BS (see 6.3.20.5).
The following parameters may be included in the RNG-REQ message when the MS is attempting to perform re-entry, association or handover:
MS MAC Address
MS MAC Address shall be included if HO_ID is omitted.
The following TLV parameter may be included in the RNG-REQ message when MS is attempting to per-form Location Update:
MAC Hash Skip Threshold
Maximum number of successive MOB_PAG-ADV messages that may be sent from a BS without individual notification for an MS, including MAC address hash of an MS for which Action Code is 00, No Action Required .
The following TLV parameter shall be included in the RNG-REQ message when the MS is attempting to perform Location Update due to power down:
Power Down Indicator
Indicates the MS is currently attempting to perform Location Update due to power down.
The following parameter may be included in RNG-REQ message when the MS is attempting to perform handover and needs to inform target BS of its preference to continue in Sleep Mode after handover to target BS.
Power_Saving_Class_Parameters
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
The following parameter may be included in the RNG-REQ message when the MS is attempting to perform network re-entry or handover and the MS has a valid HMAC/CMAC Tuple necessary to expedite security authentication.
HMAC/CMAC Tuple (see 11.1.2)
The HMAC/CMAC Tuple shall be the last attribute in the message.
6.3.2.3.6 Ranging Response (RNG-RSP) message [Insert the following at the end of 6.3.2.3.6:]
When a BS sends a RNG-RSP message in response to a RNG-REQ message containing serving BSID, the BS may include the following TLV parameter in the RNG-RSP message:
Service Level Prediction This value indicates the level of service the MS can expect from this BS. The following encodings apply:
0 =No service possible for this MS.
1 =Some service is available for one or several service flows authorized for the MS.
2 =For each authorized service flow, a MAC connection can be established with QoS specified by the AuthorizedQoSParamSet.
3 =No service level prediction available.
A Service Level Prediction may be accompanied by a number of service flow Encodings as specified in 11.13 sufficient to uniquely identify the AuthorizedQoSParamSet associated with the Service Level Predic-tion (SLP). If service flow encodings are included, then the SLP response is specific to the presented Autho-rizedQoSParamSet defined by the associated encodings. Included service flow encodings are restricted to the following parameters only:
Global Service Class Name.
Service flow QoS parameter set encodings as defined in 11.13 such that the combination of Global Ser-vice Class Name and any serSer-vice flow modifying parameters fully defines an AuthorizedQoSParamSet profile being assessed.
Service flow Identifier.
If individual AuthorizedQoSParamSet profiles are provided for multiple Service Level Predictions, then each Service Level Prediction is specific to its associated AuthorizedQoSParamSet profile and shall include only response options 0 or 2.
When a BS sends a RNG-RSP message in response to a RNG-REQ message containing Paging Controller ID, the BS shall include the following TLV parameter in the RNG-RSP message:
Location Update Response
Response to Idle Mode LocationUpdate Request:
0b00=Failure of Idle Mode Location Update. The MS shall perform Network Re-entry from Idle Mode
0b01=Success of Idle Mode Location Update 0b10, 0b11: Reserved
Paging Information
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
New Paging Information assigned to MS. Paging Information shall only be included if Loca-tion Update Response = 0b01 and if Paging InformaLoca-tion has changed.
Paging Controller ID
Paging Controller ID is a logical network identifier for the serving BS or other network entity retaining MS service and operational information and/or administering paging activity for the MS while in Idle Mode. Paging Controller ID shall only be included if Location Update Response = 0b01 and if Paging Controller ID has changed.
The following TLV parameter shall be included in the RNG-RSP message when the MS is attempting to per-form network re-entry or handover and the target BS wishes to identify re-entry process management mes-sages that may be omitted during the current HO attempt:
HO Process Optimization
Identifies re-entry process management messages that may be omitted during the current HO attempt due to the availability of MS service and operational context information obtained by means that are beyond the scope of this standard, and the MS service and operational status post-HO completion. The target BS may elect to use MS service and operational information obtained over the backbone network to build and send unsolicited SBC-RSP and/or REG-RSP management messages to update MS operational information. The MS shall not enter Normal Operation with Target BS until completing receiving all network re-entry, MAC management message responses as indicated in HO Process Optimization.
The following parameter may be included in RNG-RSP message transmitted in response to RNG-REQ mes-sage containing MAC Hash Skip Threshold:
MAC Hash Skip Threshold
Maximum number of successive MOB_PAG-ADV messages that may be sent from a BS with-out individual notification for an MS, including MAC address hash of an MS for which Action Code for the MS is 00, ’No Action Required’.
The following TLV parameter shall be included in the RNG-RSP message when the periodic ranging in sleep operation completes and the serving BS decides to assign a new SLPID for the MS:
SLPID_Update (11.16.1)
The SLPID_Update is a compound TLV value that provides a shorthand method for changing the SLPID used by the MS during sleep mode operation. The SLPID_Update TLV specifies new SLPID replacing old SLPID.
The following parameter may be included in RNG-RSP message by the BS to activate or deactivate Power Saving Class of type II and type III.
Power_Saving_Class_Parameters
Compound TLV to specify Power Saving Class operation.
The following TLV parameter may be included in RNG-RSP message transmitted the BS permits an activa-tion of Power Saving Class. This TLV indicates the enabled acactiva-tion that MS performs upon reaching trigger condition in Sleep Mode.
Enabled-Action-Triggered
Indicates possible action upon reaching trigger condition
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
for which the BS has a current HO ID value:
HO_ID
Optional ID assigned for use in initial ranging to the target BS once this BS is selected as the target BS (see 6.3.20.5).
The following TLV parameter shall be included for the BS to notify the MS of known future Next Periodic Ranging for the MS with its serving BS:
Next Periodic Ranging
Indicates the Frame Offset for the next periodic ranging opportunity. This value shall be set to zero to indicate that there has been DL traffic addressed to the MS.
The following parameter, necessary to expedite security authentication, shall be included in the RNG-RSP message when the BS notifies the MS through the HO Process Optimization TLV that the PKM-REQ/RSP sequence may be omitted for the current HO re-entry attempt, or when the BS wishes to acknowledge a valid HMAC/CMAC Tuple in the acknowledged RNG-REQ management message:
HMAC/CMAC Tuple (see 11.1.2)
The HMAC/CMAC Tuple shall be the last attribute in the message.
The following TLV parameter shall be included in the RNG-REQ message when a BS sends RNG-RSP message as a reply to the RNG-REQ message from a MS which is performing Location Update due to power down and:
Power Down Response
Indicates the MS s Power Down Location Update result.
0x00= Failure of Power Down Information Update.
0x01= Success of Power Down Information Update The following TLVs may be present in RNG-RSP (see section 7.8.1) PKMv2 SA-TEK-Challenge Tuple (11.7.23)
This carries the initial challenge of the 3way handshake.
6.3.2.3.7 Registration request (REG-REQ) message [Change the third paragraph below Table 21 as follows:]
The REG-REQ shall contain the following TLVs:
Hashed Message Authentication Code (HMAC)/CMAC Tuple Shall be final attribute in the message s TLV attribute list (11.1.2).
In Mesh Mode, message digest is calculated using HMAC_KEY_U.
[Change the fourth paragraph below Table 21 as follows:]
For PMP operation, the REG-REQ shall contain the following TLVs:
Uplink CID Support (11.7.6)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
SS management support (11.7.2) IP management mode (11.7.3)
[Insert the following text at the end of 6.3.2.3.7]
For an MS, the REG-REQ (on initial network entry) shall contain the following TLVs:
Handover supported (11.7.12) Mobility parameters support (11.7.14) The REG-REQ may contain the following TLV:
MAC header and extended subheader support (11.7.25).
6.3.2.3.8 Registration Response (REG-RSP) message [Change the first paragraph below Table 22 as follows:]
The REG-RSP shall contain the following TLVs:
SS management support (11.7.2)
Response to REG-REQ indicating the mode of SS management operation.
Secondary Management CID (11.7.5)
Present only if the SS has indicated in the REG-REQ that it is a managed SS.
HMAC/CMAC Tuple (11.1.2)
The HMAC/CMAC Tuple attribute shall be the final attribute in the message s TLV attribute list.
In Mesh Mode, message digest is calculated using HMAC_KEY_D.
[Insert the following text into the end 6.3.2.3.8]
For mobile stations, when the information is available to create CID update TLV, the target BS shall include the CID_update and SAID_update TLVs in the REG-RSP for an MS recognized by the target BS as per-forming HO or Network Re-entry from Idle Mode. BS may include the Compressed CID Update TLV instead of the CID_update TLV in REG-RSP message if CID update procedure is required. The target BS recognizes an MS performing Network Re-entry from Idle Mode by the presence of a serving BSID or Pag-ing Controller ID and RangPag-ing Purpose Indication with bit#0 set to 1 in the RNG-REQ message.
CID_update
The CID_update is a compound TLV value that provides a shorthand method for replacing the active connections used by the MS in its previous serving BS. Each CID_update TLV specifies a CID in the target BS that shall replace a CID used in the previous serving BS. Multiple instances of CID_update may occur in the REG-RSP to facilitate re-creating and re-assigning admitted or active service flows for the MS from its previous serving BS. If any of the service flow parameters change (including Target SAID, see 11.3.18), then those service flow parame-ter encoding TLVs that have changed will be added. If the BS cannot re-establish a particular service flow, it shall not include an instance of CID_update for that service flow.
These TLVs enable the target BS to renew connections used in the previous serving BS, but with different QoS settings.
Compressed CID_update
The Compressed CID_update TLV also provides a method for replacing the active connections used by the MS in its previous serving BS as CID update TLV. It can diminish the length of
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
SAID_update
The SAID_update is a compound TLV value that provides a shorthand method for renewing active SAs used by the MS in its previous serving BS. The TLVs specify SAID in the target BS that shall replace active SAID used in the previous serving BS. Multiple iterations of these TLVs may occur in the REG-RSP suitable to re-creating and re-assigning all active Security Associations for the MS from its previous serving BS including Primary, Dynamic and Static SAIDs. If any of the Security Associations parameters change, then those Security Associations parameters encoding TLVs that have changed will be added.
When a BS has multiple number Provisioned service flows to transmit to an MS, the BS may include Total number of Provisioned service flow TLV (11.7.19).
The REG-REQ may contain the following TLV:
MAC header and extended subheader support (11.7.25).
For an MS, the REG-RSP (on initial network entry) shall contain the following TLVs:
Handover supported (11.7.11)
Mobility parameters support (11.7.13)\
6.3.2.3.9 Privacy key management (PKM) messages (PKM-REQ/PKM-RSP) [Modify the text directly below Table 24 as indicated:]
PKM protocol messages transmitted from the BS to the SS shall use the form shown in Table 25. They are transmitted on the SSs Primary Management Connection. When the BS sends PKM-RSP message in key push mode to MS for multicast service or broadcast service, it may be carried on the Broadcast connection.
[Change the text between Table 25 and Table 26 as indicated:]
The parameters shall be as follows:
Code
The Code is one byte and identifies the type of PKM packet. When a packet is received with an invalid Code, it shall be silently discarded. The code values are defined in Table 26.
PKM Identifier
The Identifier field is one byte. An SS uses the identifier to match a BS response to the SS requests. In the case of 3 way SA-TEK procedure, however, a BS uses it to match an SS response to the BS’s challenges.
The SS shall increment (modulo 256) the Identifier field whenever it issues a new PKM message. In PKMv1, a A "new" message is an Authorization Request or Key Request that is not a retransmission being sent in response to a Timeout event. In PKMv2, a PKMv2 RSA-Request, PKMv2 SA-TEK-Challenge, or PKMv2 Key-Request message is a "new" message. For retransmissions, the Identifier field shall remain unchanged.
The Identifier field in PKMv2 EAP-Transfer messages, PKMv2 Authenticated EAP messages, and in Authentication Information messages, which are informative and do not effect any response messaging, shall be set to zero. The Identifier field in a BS s PKM-RSP message shall match the Identifier field of the PKM-REQ message the BS is responding to. The Identifier field in TEK Invalid messages and PKMv2 TEK Invalid messages, which are not sent in response to PKM-REQs, shall be set to zero. The Identifier field in PKMv2 Group unsolicited Authorization Invalid messages shall be set to zero. The Identifier field in