July 2007
doc.: IEEE 802.22-07/0383r0
IEEE P802.22
Wireless RANs
Proposed enhancements to the PHR and the initialization bit
Date: 2007-31-07
Author(s):
Name
Jinxia Cheng
David Mazzarese
Baowei Ji
Shan Cheng
Euntaek Lim
Company
CHINA SAMSUNG
Telecom R&D Center
Samsung Electronics
Samsung
Telecommunications
America
Samsung Electronics
Samsung Electronics
Address
jinxia.cheng@samsung.com
Korea
Phone
86-10-64390088
Ext.3112
+82 10 3279 5210
USA
+1 972-761-7167
BJi@sta.samsung.com
Korea
Korea
+82 31 279 7557
+82 31 279 5917
cheng.shan@samsung.com
et.lim@samsung.com
China
email
d.mazzarese@samsung.com
Abstract
In the current draft, PHR is only 1 octet which contains 1 uncoded inititalization bit and 7
reserved bits. There is 1 octet for zero padding at the end of the PPDU. In order to guarantee the
quality of traffic in the inter-beacon communication channel, suggested text is included in this
document for utilizing 5-repetition initialization bits. On the other hand, more information might be
needed in the future in the PHR, suggest text is also included for removing the padding octet to
increase the length of the PHR to 2 octets.
Notice: This document has been prepared to assist IEEE 802.22. It is offered as a basis for discussion and is not binding on the
contributing individual(s) or organization(s). The material in this document is subject to change in form and content after
further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution,
and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE
Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and
accepts that this contribution may be made public by IEEE 802.22.
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures
<http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known
use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with
respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the
Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in
the development process and increase the likelihood that the draft publication will be approved for publication. Please notify
the Chair <Carl R. Stevenson> as early as possible, in written or electronic form, if patented technology (or technology under
patent application) might be incorporated into a draft standard being developed within the IEEE 802.22 Working Group. If you
have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
Submission
page 1
Jinxia Cheng, Samsung
July 2007
doc.: IEEE 802.22-07/0383r0
This document is submitted for illustrating a letter ballot comment we have made to P802.22.1/D1.
Problem with Section 5.5 Beacon frame structure:
[ Refer to Section 5.5 for the 1 initialization bit, 1 octet PHR and 1 octec zero padding bits. ]
The PHR is 1 octet and contains 1 uncoded bit (the initialization bit) and 7 reserved bits. There is 1 octet
for zero padding at the end of the PPDU. More information may be needed in the future in the PHR, so it would
be good to remove the padding bits and to increase the length of the PHR to 2 octets. The robustness of the
initialization bit is not good enough, considering that it has an impact on the traffic in the inter-beacon
communication channel.
Firstly, we propose to make the PHR 2 octets and to remove the zero padding bits. Note that by doing
that, PHR+MSF1 (encoded) is 2+17*2 bits = 36 octets = 9 slots = 29.9722 ms. In order to decode the MSF1, the
receiver must first synchronize with the sync sequence contained in the sync burst. So whether the PHR is 1 or 2
octets, the receiver needs to listen for 9 complete slots. So there is no impact on the required minimum quiet
period.
Secondly, in order to improve the robustness of the initialization bit, we propose to repeat it 3 or 5 times
in the PHR. Note that the PHR does not need to be heard as far as the coded bits in MSF1, since it is relevant only
for short-range inter-beacon communication. This is why we propose to improve its robutsness only slightly with
a low complexity repetition code.
Finally, with the two proposals above, the PHR becomes 2 octets. The first 3 (or 5) bits are repetitions of
the initialization bit, and the next 13 (or 11) bits are set to zero and reserved for future use.
In Figure 1, we simulated the error probability of initialization bits detection with different number of
repetition in channel B. It can be seen that 5-repetition will achieve a higher performance gain compared with 1bit initialization bit. For fading environment, 7-repetition could not get obvious gains compared with 5-time
repetition. On the other hand, it will take a larger overhead. Therefore, with the full consideration of both
performance and overhead, 5-repetition for 2-octet PHR and 3-repetition for 1-octet PHR will be a better choice.
Submission
page 2
Jinxia Cheng, Samsung
July 2007
doc.: IEEE 802.22-07/0383r0
0
Error probality of initilization bits detection
10
no repetition (LOS)
-1
10
3-repetition (LOS)
5-repetition (LOS)
no repetition (Rayleigh)
3-repetition (Rayleigh)
5-repetition (Rayleigh)
7-repetition (LOS)
-2
10
7-repetition (Rayleigh)
-3
10
2
4
6
8
10
12
14
16
18
Es/No (dB)
Figure 1. Error probability of initialization bits detection with various number of repetitions.
Suggested text for enhancement to the PHR and the initialization
bit
Modify Figure 5-Schematic view of the beacon frame and PHY packet (PPDU) on page 13 as shown below:
Submission
page 3
Jinxia Cheng, Samsung
July 2007
doc.: IEEE 802.22-07/0383r0
Octets 1
MAC
sublayer
6
6
1
1
2
5
44
2
31
2
Channel/
Parameter Source
Parameter Parameter CRC
CRC
CRC
Subchannel Signature
Location
Certificate
1
Address
2
3
2
3
1
Map
MSF 1
MSF 2
MSF 3
MPDU
Octets 2
PHY
sublayer
Reserved
(11 bits)
101(MPDU)+17(coding of MSF1)
Initialization
(5 bits)
PHR
PSDU
PHY payload
Figure 5-Schematic view of the beacon frame and PHY packet (PPDU)
Modify section 5.5 Beacon frame structure as shown bellows:
Figure 5 shows the structure of the beacon frame, which originates from within the MAC sublayer of either the
PPD or an SPD. The beacon frame contains three MAC subframes (MSF). Each MSF is composed of a MAC
header (MHR) and a MAC footer (MFR). The MHR in MSF1 contains the three MAC parameter fields, the
Source Address field, and the Location field. The MHR in MSF2 contains the Channel/Subchannel Map and
Signature fields, while the MHR in MSF3 contains the Certificate field; the Signature and Certificate fields are
part of the public-key cryptography security solution (5.6.1). The MFR1, MFR2 and MFR3 contain a 2-octet
CRC. The three MSFs together form the MAC protocol data unit (MPDU), which has the same contents as the
unencoded PHY service data unit (PSDU).
The MAC beacon frame is passed to the PHY as the unencoded PSDU (or unencoded PHY payload). The MSF1
in the PHY payload is protected by a half-rate convolutional code (6.8.2.2), and the addition of this code increases
the payload length by 17 octets. The PHY payload is then prefixed with a PHY header (PHR), containing the
initialization bit. The PHR and PHY payload together form the PHY protocol data unit (PPDU) (i.e., the PHY
packet). The PHY payload is then prefixed with a PHY header (PHR), containing 5-repetition initialization bits
and 11 reserved bits. The PHR and PHY payload together form the PHY protocol data unit (PPDU) (i.e., the PHY
packet). The overall length of the PPDU is 120 octets.
Because the length of a synchronization burst is 4 octets, zero padding is added to the end of the PPDU (i.e.,
following MSF 3) to ensure that its length is a multiple of four. Therefore, the overall length of the PPDU is 120
octets.
Modify section 6.4 PPDU format as shown belows:
Submission
page 4
Jinxia Cheng, Samsung
July 2007
doc.: IEEE 802.22-07/0383r0
Each PPDU packet consists of a constant length payload of length 120 octets, which carries the MAC sublayer
beacon frame. The beacon frame is divided into three MAC subframes (MSF), as shown in Figure 5 of Clause 5,
and is passed to the PHY layer for inclusion in the PHY payload.
A half-rate convolutional code with puncturing shall be applied by the PHY layer to the first MAC subframe
(MSF 1), which includes the three MAC parameter fields, the Source Address field, the Location field, and a 2octet CRC. The addition of this convolutional code with puncturing increases the PHY payload length by 17
octets, bringing the total length to 118 octets. A PHY header containing one initialization bit and seven reserved
bits shall be appended to the start of the encoded PHY payload; the initialization bit indicates whether or not the
beacon frame will be followed by a receive period and corresponding ANP burst. Then, because the length of a
synchronization burst is 4 octets, zero padding shall be added to the end of the PPDU (i.e., following MSF 3) to
ensure that its length is a multiple of four. Therefore, the overall length of the PPDU is 120 octets. A PHY header
containing five initialization bits with the same value and eleven reserved bits shall be appended to the start of the
encoded PHY payload; the initialization bits indicated whether or not the beacon frame will be followed by a
receive period and corresponding ANP burst. The overall length of the PPDU is 120 octets.
For the PPDU packet structure, the multiple octet field shall be transmitted or received least significant octet first
and each octet shall be transmitted or received least significant bit (LSB) first.
Modify section 7.4.4 Device initialization procedure as shown belows:
Upon initialization, a protecting device shall identify the channel it is to monitor, then monitor that channel for a
period of 2 + 0.01m continuous seconds, where m is an integer selected at random from the set [0, 1, 2, …, 98, 99,
100], to determine the presence or absence of a PPD. A PPD is determined to be present on the channel if the
protecting device receives a beacon frame.
The monitoring operation may be initiated by the next higher layer of the protecting device via the MLMESCAN.
request primitive. Any beacon frame received during the scan shall be passed to the next higher layer via the
MLME-INCOMING-BEACON.indication primitive.
At the conclusion of this initial monitoring period, if the protecting device determines that there is no PPD already
present on the channel (i.e., no beacon frame was detected), the protecting device may, at the discretion of the
next higher layer, promote itself to PPD and begin transmitting periodic beacon frames. Beacon frame
transmission is initiated by the next higher layer via the MLME-START-BEACON.request primitive with the
Periodic parameter set to TRUE, indicating that periodic beacon frames are to be transmitted.
During this initial transmission period, the new PPD shall set the initialization bit in the PHR to one and transmit
a continuous series of superframes, which shall not include receive periods or ANPs, for a period of 30 seconds.
During this initial transmission period, the new PPD shall set all 5-repetition initialization bits in the PHR to one
and transmit a continuous series of superframes, which shall not include receive periods or ANPs, for a period of
30 seconds. Each superframe shall be composed of 31 synchronization bursts sent on the synchronization channel.
A 120-octet length beacon frame followed by 4 octets of all zeros shall be sent on the beacon channel (7.4.1).
Following the initial transmission period, superframe transmission shall continue; however, the receive period and
ANP shall be inserted immediately following the beacon frame. Since the receive period and ANP together have a
duration of one slot time, the number of synchronization bursts in a superframe following the initial transmission
period is 30.
The superframe shall always have a period equal to (8*124) bits/9609.1 Hz = 103.24 ms.
At the conclusion of the initial monitoring period, if the protecting device determines that there is a PPD on the
channel (i.e., a beacon frame was detected), the protecting device may, at the discretion of the upper layer, send
its information to the PPD for inclusion in the PPD's beacon frame rather than begin its own superframe
transmissions (i.e., opt to become an SPD). This may be accomplished by the protecting device synchronizing to
Submission
page 5
Jinxia Cheng, Samsung
July 2007
doc.: IEEE 802.22-07/0383r0
the superframe of the PPD, transmitting an RTS burst during the receive period, and then transmitting its own
beacon frame containing the information it wishes the PPD to include in future beacon frames. For more details,
see 7.4.5.
If the device does opt to become an SPD, the next higher layer should write the address of the PPD into the MIB
attribute macPPDAddress via the MLME-SET.request primitive.
Modify section 7.4.7.1 Primary protecting device (PPD)
A probable scenario is that the PPD will cease transmission abruptly. Because the SPD is continuously monitoring
the channel, the MAC sublayer of the SPD shall issue an MLME-BEACON-LOST.indication primitive to the
next higher layer once macMaxMissedBeaconsSPD consecutive beacon frames are missed, thus alerting the next
higher layer that the device it is protecting is no longer protected by the PPD's beacon. The action taken by the
next higher layer on receipt of this primitive is out of the scope of this standard. One option, however, is for the
SPD to promote itself to PPD and begin transmitting periodic beacons frames.
If the PPD is aware that it is about to cease transmission, it shall set the Cease Tx subfield in the beacon header to
one upon sending its last beacon frame. The next higher layer of the SPD shall be notified through the MLMEINCOMING-BEACON.indication primitive. Again, the action taken by the next higher layer on receipt of this
primitive is out of the scope of this standard.
If an SPD does promote itself to PPD, this new PPD shall not be required to set the initialization bit in the PHR to
one for a period of thirty seconds, as is required for a PPD following the device initialization procedure (7.4.4). If
an SPD does promote itself to PPD, this new PPD shall not be required to set all the 5-repitition bits in the PHR to
one for a period of thirty seconds, as is required for a PPD following the device initialization procedure (7.4.4).
The new PPD shall initially continue to transmit the same beacon parameters as the original PPD. However, the
following update procedure should be followed such that the PPD will eventually have the most current
information.
Any SPD in the area shall receive the beacon frame, note that the Source Address field in the beacon frame has
changed (i.e., the Source Address field is different from the value of macPPDAddress) and set the value of
macPPDAddress to the value of the Source Address field. The SPD should then interrupt the PPD to send its own
beacon frame (see 7.4.5.2). Eventually very SPD should interrupt the PPD to send a beacon frame, ensuring that
the PPD has the most current information.
References:
[1] Part 22.1: Enhanced Protection for Low-Power, Licensed Devices Operating in Television Broadcast Bonds,
P802.22.1/D1, May 2007
Submission
page 6
Jinxia Cheng, Samsung