This post discusses the topic related to OCC MAC and MPDU.
IEEE 802.15.7m OCC MAC Layer
“Use of over-the-air MAC frame configuration is forbidden for PHY types IV, V and VI. It is mandatory MAC frame configuration be done via the MAC PIB. This is due to the fact that unlike traditional wireless LAN/PAN, the data rates associated with OCC are such that the configuration overhead cannot be tolerated. This means that there is no “base default” transmission mode. In addition, it is anticipated that configuration will be with application layer “APPS” that are specifically loaded to support a particular OCC PHY mode. The MAC PIB is not transmitted; rather, it is written by the Device Management Entity and is read by the MAC layer.” – IEEE 802.15.7m
OCC MAC Configuration Concept

The VPAN device architecture in Figure 1 suggests the consideration on MLME-SAP and PLME-SAP through device management entity. How does this architecture impact to the MAC and MPDU in OCC? To answer this question, at first we should have a basic understanding about MAC sublayer service specification.
MAC sublayer service specification
The MAC sublayer provides an interface between the SSCS, DME and the PHY. The MAC sublayer conceptually includes a management entity called the MLME.
So we quickly define what MLME is, for more understanding, I suggest you to take a look at the standard. MLME is the thing to manage MAC PIB which is our target soon.

A broader view of the entire APP is illustrated in Figure 3. Yes, MAC PIB now is the target to define the OCC link. MAC PIB contains a lot of the information related to how MAC operates and how MPDU is configured.

Quick question: So what about MPDU format in OCC? Why MAC PIB is so important in OCC?
IEEE 802.15.7m OCC MAC Frame Format (MPDU)
“Use of over-the-air MAC frame configuration shall not be done for PHY types IV, V and VI, which shall accomplish MAC frame configuration via the MAC PIB. There shall be no “base default” transmission mode for PHY types IV, V and VI. The MAC PIB shall not be transmitted; rather, it shall be written by the Device Management Entity which shall be read by the MAC layer.” – IEEE 802.15.7m.
This standard text explains how MAC PIB is important. Now let’s take a look on how OCC MPDU formats different!
Table 1 – Summary on Initial OCC MAC frame formats
MHR |
MSDU |
MFR |
||
IEEE 802.15.7-2011 |
|
Frame payload | FCS | |
OCC
PHY IV |
UFSOOK |
x |
– | CRC-3 |
S2-PSK |
x |
– | x | |
S8-PSK |
x |
– | x | |
Twinkle VPPM | Addressing fields (source) | – | FCS | |
HS-PSK | Addressing fields | – | Optional | |
Offset-VPPM | x | – | FCS: 2 | |
OCC
PHY V |
RS-FSK |
|
– | FCS: 2 |
CM-FSK | Config. via MAC attributes | – | x | |
C-OOK | Config. via MAC attributes | – | x | |
MPM | N/A | N/A | N/A | |
OCC
PHY VI |
A-QL |
|
– | Optional |
HA-QL | Config. via MAC attributes | – | x | |
VTASC |
|
– | FCS: 2 | |
IDE |
Because there is the only one MAC for all of OCC modes, so these MAC formats are merged into a single MAC format off course.
Some comments on OCC MAC:
- If the frame control field is disabled, there is no need of MAC supper frame. Thus, low-rate OCC modes without MHR field on MAC shall be implemented in information broadcasting (IB mode). In fact, OCC MAC follows un-slotted ALOHA mechanism.
- When MHR is disabled, multiple MACs may be supported in the same network by re-configuring the MAC attributes.
- Frame control field is necessary at a situation that D2D is supported. A TRX generates a source address when it broadcasts data to multiple TRXs, and it generates a destination source address when it solely targets the communication to a specific one.
Newly-added MAC PIBs for OCC
As given that the use of over-the-air MAC frame configuration shall not be done for OCC modes, new MAC PIBs are added to support the configuration of MAC and MPDU format through the DME for OCC.
Table 2 – Summary of MAC PIBs adding for OCC
Newly-Added MAC PIBs |
Explanation on usage |
|
The next higher layer or the DME indicates the Led Id Ambiguity Resolution to the MAC using this MAC PIB attribute. |
|
The MAC configures its MPDU format using these MAC PIB attributes.
|
Table 3 – MAC PIB attributes Description
Attribute | ID | Type | Range | Description | Default |
macLedIdAmbiguityResoluti
on |
0x71 | Unsigned | 0-255 | This attribute resolves the ambiguity of a short LED ID by appending it to a SSID as shown in Table 3. | 0 |
macFrameControl | 0x72 | Unsigned | 2 octets | This attribute specifies MAC frame control field configuration. | 0 |
macSequenceNumber | 0x73 | Unsigned | 1 octet | This attribute specifies MAC sequence number field configuration. | 0 |
macDestinationOWPANIde
ntifer |
0x74 | Unsigned | 2 octets | This attribute specifies MAC destination OWPAN ID field configuration. | 0 |
macDestinationAddress | 0x75 | Unsigned | 2 or 8 octets | This attribute specifies MAC destination address field configuration. | 0 |
macSourceOWPANIdentifie
r |
0x76 | Unsigned | 2 octets | This attribute specifies MAC source OWPAN ID field configuration. | 0 |
macSourceAddress | 0x77 | Unsigned | 2 or 8 octets | This attribute specifies MAC source address field configuration. | 0 |
macAcknowledgeField | 0x78 | Unsigned | variable length | This attribute specifies MAC acknowledge field configuration. | 0 |
macFramePayload | 0x79 | Unsigned | variable length | This attribute specifies MAC frame payload field configuration. | 0 |
macFCS | 0x7a | Unsigned | 2 octets | This attribute specifies MAC FCS field configuration | 0 |
macMsduLength | 0x7b | Unsigned | 0-65535 | This attribute specifies the length of MSDU in the bit unit. | 0 |
Table 4 – OCC Ambiguity Resolution Method
PIB Attribute Value | Method Name | Method |
0 | ID without payload | Preappend ID to SSID |
1 | ID and SSID hash | Preappend ID to hash resolved SSID |
2 | w/ or w/o ID and IP address | Preappend ID to provided IP address |
there is no “base default” transmission mode
Can you tell me the meaning of this statement? What is Base Default?
LikeLike
@Kumar the standard is a complex doc with over 300 pages. Different PHY modes should must be realized by the supported devices. Therefore, it typically requires a “base mode” or “common mode” to allow devices for talking to each other. OCC standard does not use this typical option due to low data rates.
LikeLike