ISO/IEC 29157:2010

Information technology - Telecommunications and information exchange between systems - PHY/MAC specifications for short-range wireless low-rate applications in the ISM band

ISO/IEC 29157:2010 specifies the physical layer (PHY) characteristics and medium access control (MAC) procedures used for short-range, low-data-rate, wireless communications with very low latency and point-to-multipoint connection capability in the industrial, scientific and medical (ISM) band.

Technologies de l'information — Téléinformatique — Spécifications PHY/MAC pour applications à bas débit sans fil à courte portée dans la bande ISM

General Information

• Status: Withdrawn
• Publication Date: 08-Jun-2010
• Withdrawal Date: 08-Jun-2010
• ICS: 35.110 - Networking
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 1 - Physical and data link layers
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 17-Jul-2015
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 29157:2015 - Information technology - Telecommunications and information exchange between systems - PHY/MAC specifications for short-range wireless low-rate applications in the ISM band
• Effective Date: 06-Aug-2011

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29157
First edition
2010-06-15
Information technology —
Telecommunications and information
exchange between systems — PHY/MAC
specifications for short-range wireless
low-rate applications in the ISM band —
Technologies de l'information — Téléinformatique — Spécifications
PHY/MAC pour applications à bas débit sans fil à courte portée dans la
bande ISM —
Reference number
©
ISO/IEC 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved

Contents Page
Foreword .viii
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviated terms.2
5 Overview.3
6 Interlayer service specification.5
6.1 Overview.5
6.2 General format of management primitives .6
6.2.1 MLME-GET.request and PLME-GET.request .7
6.2.2 MLME-GET.confirm and PLME-GET.confirm.7
6.2.3 MLME-SET.request and PLME-SET.request.8
6.2.4 MLME-SET.confirm and MLME-SET.confirm.8
6.3 MLME-SAP .9
6.3.1 MLME-GET.request .10
6.3.2 MLME-GET.confirm .10
6.3.3 MLME-MASTER-START.request .10
6.3.4 MLME-MASTER-START.confirm .11
6.3.5 MLME-RESET.request.11
6.3.6 MLME-RESET.confirm.12
6.3.7 MLME-SCAN.request.12
6.3.8 MLME-SCAN.confirm .13
6.3.9 MLME-SET.request.13
6.3.10 MLME-SET.confirm.14
6.4 MAC-SAP.14
6.4.1 MAC-DATA.request .15
6.4.2 MAC-DATA.confirm.15
6.4.3 MAC-DATA.indication .16
6.5 PLME-SAP .16
6.5.1 PLME-GET.request.17
6.5.2 PLME-GET.confirm.17
6.5.3 PLME-SET.request .18
6.5.4 PLME-SET.confirm .18
6.5.5 PLME-RESET.request .19
6.5.6 PLME-RESET.confirm .19
6.6 PD-SAP .19
6.6.1 PD-DATA.request .20
6.6.2 PD-DATA.confirm .20
6.6.3 PD-DATA.indication .21
7 MAC PDU format.21
7.1 MPDU of beacon frame (BF).22
7.1.1 Open flag (OF, 2 bits) .22
7.1.2 MAC version (6 bits).22
7.1.3 Address mode (ADDM, 2 bits).22
7.1.4 PHY version (6 bits).22
7.1.5 Frame type (8 bits).22
7.1.6 Superframe mode control (SFMC, 2 bits).23
7.1.7 Upper layer frame size (ULFS, 6 bits).23
7.1.8 Source MAC address (64 bits) .23
© ISO/IEC 2010 – All rights reserved iii

7.1.9 Superframe counter (SFC, 4 bits).23
7.1.10 Middleframe counter (FC, 4 bits).23
7.1.11 Hopping sequence (32 bits).24
7.1.12 BF frequency table (BFFT, 16 bytes) .24
7.1.13 Upper layer data (16 bytes).24
7.2 MPDU of fast beacon frame (FBF).24
7.2.1 Open flag (OF, 2 bits) .24
7.2.2 MAC version (6 bits) .24
7.2.3 Address mode (ADDM, 2 bits) .24
7.2.4 PHY version (6 bits).24
7.2.5 Frame type (8 bits).24
7.2.6 Superframe mode control (SFMC, 2 bits).24
7.2.7 Upper layer frame size (ULFS, 6 bits) .24
7.2.8 Source MAC address (64 bits).25
7.2.9 Superframe counter (SFC, 4 bits).25
7.2.10 Middleframe counter (SC, 4 bits).25
7.2.11 Hopping sequence (32 bits).25
7.2.12 BF frequency table (BFFT, 16 bytes) .25
7.2.13 Upper layer data (16 Bytes) .25
7.3 MPDU of request control frame (RCF).26
7.3.1 Open flag (OF, 2 bits) .26
7.3.2 MAC version (6 bits) .26
7.3.3 Address mode (ADDM, 2 bits) .26
7.3.4 PHY version (6 bits).26
7.3.5 Frame type (8 bits).26
7.3.6 Upper layer frame size (ULFS, 6 bits) .26
7.3.7 Source MAC address (64 bits).26
7.3.8 Destination MAC address (64 bits) .26
7.3.9 Upper layer data.26
7.4 MPDU of master control frame (MCF).27
7.4.1 Open flag (OF, 2 bits) .27
7.4.2 MAC version (6 bits) .27
7.4.3 Address mode (ADDM, 2 bits) .28
7.4.4 PHY version (6 bits).28
7.4.5 Frame type (8 bits).28
7.4.6 Upper layer frame size (ULFS, 6 bits) .28
7.4.7 Source MAC address (64 bits).28
7.4.8 Destination MAC address (64 bits) .28
7.4.9 Upper layer data.29
7.5 MPDU of RCF acknowledge control frame (RACF) .29
7.6 MPDU of MCF acknowledge control frame (MACF) .29
7.7 MPDU of payload frame (PF) .29
7.7.1 Open flag (OF, 2 bits) .29
7.7.2 MAC version (6 bits) .29
7.7.3 Address mode (ADDM, 2 bits) .29
7.7.4 PHY version (6 bits).29
7.7.5 Frame type (8 bits).29
7.7.6 Upper layer frame size (ULFS, 6 bits) .30
7.7.7 Source MAC address (64 bits).30
7.7.8 Destination MAC address (64 bits) .30
7.7.9 Upper layer data.30
8 MAC functional description.31
8.1 General description .31
8.2 System state diagram.31
8.3 Protocol structure.33
8.3.1 Middleframe structure .34
8.3.2 Superframe structure .34
8.4 Frequency operation .36
8.4.1 Frequency hopping control .36
iv © ISO/IEC 2010 – All rights reserved

8.4.2 Frame frequency mapping .36
8.4.3 Frequency diversity and time diversity.37
8.4.4 Orthogonal frequency offset .37
8.4.5 Frequency selection.37
9 PHY specification .40
9.1 General requirements .40
9.1.1 Operating frequency range .40
9.1.2 Frequency assignment .40
9.1.3 Frequency synthesizer stabilisation time.40
9.1.4 Frequency synthesizer turn off time .41
9.2 PHY protocol data unit (PPDU) format.41
9.2.1 Lock time.41
9.2.2 Preamble (128 bits).41
9.2.3 Header (48 bits).42
9.2.4 Message .42
9.2.5 EoF delimiter.42
9.3 Modulation and codes.42
9.3.1 Modulation .42
9.3.2 Codes.43
9.4 Transmitter specification.44
9.4.1 Pulse shaping filter .44
9.4.2 Transmitter power spectrum mask.44
Bibliography.45

© ISO/IEC 2010 – All rights reserved v

Figures
Figure 1 — A group communication example. .4
Figure 2 — Data formats: a frame, a middleframe, and a superframe. .5
Figure 3 — The protocol model used in this International Standard .6
Figure 4 — MPDU in Frame structure.22
Figure 5 — MPDU format of Beacon Frame .23
Figure 6 — MPDU format of Fast Beacon Frame (FBF) .25
Figure 7 — MPDU format of RCF.27
Figure 8 — MPDU format of MCF .28
Figure 9 — MPDU format of PF .30
Figure 10 — A pico-net with only two devices. .31
Figure 11 — A pico-net with more than two terminals.31
Figure 12 — State transition diagram.33
Figure 13 — The protocol structure.34
Figure 14 — Middleframe structure .34
Figure 15 — Structure of a normal superframe .35
Figure 16 — Structure of a fast synchronisation superframe.35
Figure 17 — Superframe mode alternation .35
Figure 18 — Middleframe counter.36
Figure 19 — Superframe counter.36
Figure 20 — The hopping sequence generator .36
Figure 21 — Frame frequency mapping scheme.37
Figure 22 — Middleframe structure of passive sounding .38
Figure 23 — One cycle of passive sounding frames .38
Figure 24 — Illustration of static sounding.39
Figure 25 — Middleframe structure of static sounding .39
Figure 26 — Static sounding value.39
Figure 27 — The structure of the static sounding superframe.40
Figure 28 — PHY Protocol Data Unit (PPDU) format.41
Figure 29 — An example of Gold code generators .42
Figure 30 — Scan code .43
Figure 31 — Security code.43
Figure 32 — Group code .43

vi © ISO/IEC 2010 – All rights reserved

Tables
Table 1 — General management primitive overview .6
Table 2 — MLME/PLME general management primitive parameters .7
Table 3 — MLME primitive summary.9
Table 4 — MLME-SAP parameters.9
Table 5 — MAC-SAP primitive summary.14
Table 6 — MAC-SAP parameters .14
Table 7 — PLME-SAP primitive summary.16
Table 8 — PLME-SAP parameters .17
Table 9 — PD-SAP primitives.19
Table 10 — PD-SAP parameters .20
Table 11 — Description of states.32
Table 12 — The use of the fields in a frame.41

© ISO/IEC 2010 – All rights reserved vii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 29157 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.

viii © ISO/IEC 2010 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29157:2010(E)

Information technology — Telecommunications and information
exchange between systems — PHY/MAC specifications for
short-range wireless low-rate applications in the ISM band
1 Scope
This International Standard specifies the PHY characteristics and MAC procedures used for short-range, low-
data-rate, wireless communications with very low latency and point-to-multipoint connection capability.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
None.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
pico-net
small operational range for wireless transmissions within about 10 meters in radius from the user or his/her
device
3.2
group
total of devices interoperable within a pico-net, with their usage of the same group code separating them from
other devices in different groups
3.3
master
device transmitting the reference synchronisation signal within a group
3.4
slave
device that is not a master
3.5
scan
process performed by slaves to search for the synchronising signal from the master
3.6
middleframe
basic unit of frame operation, consisting of one control frame and one or more payload frames
NOTE Sixteen middleframes constitute a superframe.
© ISO/IEC 2010 – All rights reserved 1

3.7
superframe
bigger frame consisting of sixteen middleframes
NOTE The superframe is the overall operational unit of pico-net MAC operations.
3.8
scan code
7-bit seed to generate one of the 127 gold codes which has a value between 1 and 127
3.9
open code
code used for broadcasting
3.10
closed code
code used exclusively for a specific communication group or purpose
3.11
group code
code to discriminate among communication groups
NOTE Either an open or a closed code may be applied.
3.12
security code
code applied to message data to enhance security or privacy of the communication
NOTE Either an open or a closed code may be applied.
4 Abbreviated terms
BF beacon frame
DME device management entity
FBF fast beacon frame
FSK frequency shift keying
GFSK Gaussian frequency shift keying
ISM industrial, scientific, and medical
MAC medium access control
MACF MCF acknowledge control frame
MCF master control frame
MLME MAC sublayer management entity
MLME-SAP MAC sublayer management entity-service access point
MPDU MAC protocol data unit
MSDU MAC service data unit
PD-SAP PHY data service access point
2 © ISO/IEC 2010 – All rights reserved

PDU protocol data unit
PF payload frame
PHY physical layer
PLME physical layer management entity
PLME-SAP physical layer management entity - service access point
PPDU physical layer protocol data unit
PSDU physical layer service data unit
RACF RCF acknowledge control frame
RCF request control frame
RF radio frequency
RSSI received signal strength indication
SAP service access point
SDU service data unit
5 Overview
There may be many applications in the ISM band. Such applications that require a short-range wireless
communication channel can be listed as follows in the order of data rates; video, audio, voice, control, sensor,
and so on. A different platform for a different application may be an ineffective way in light of cost, time-to-
market, compatibility, etc. It would be beneficial to have a single platform which is capable of accommodating
all these applications with the least overhead.
This International Standard is intended to provide a unified yet efficient and versatile platform for low-power,
low-data-rate, short-range wireless communication applications. It is possible to accommodate diverse
services of different nature in a single platform.
For mobile applications, low power consumption is one of the most important factors. To save power, data
rate should be traded-off. This International Standard aims for the applications of 1 Mbps or less. To minimise
implementation effort, it assumes the use of off-the-shelf RF components for the ISM band.
The International Standard makes use of frequency hopping, time-division multiple access, and
time/frequency hybrid diversity. Frequency hopping is adopted to render immunity to the channel variations
and to provide independent simultaneous communication channels. Time-division multiple access provides
one with the control of interference of strong adjacent signals which otherwise should be avoided using an
elaborate manipulation. The diversity technology is the means to maintain quality-of-service in the ISM band
where channel fading is of serious concern.
Each device in the pico-net formed by this International Standard is either a master or a slave. In the pico-net,
there exists only one single master which transmits a beacon signal to which all the other devices (slaves) are
synchronised. The beacon signal contains the time synchronisation information and the frequency hopping
pattern table. The frequency hopping pattern table contains the 16 best frequencies which are selected by
sounding algorithms (see 7.4.5).
© ISO/IEC 2010 – All rights reserved 3

Figure 1 — A group communication example
At start-up, the master checks the frequency channels and selects the best 16 channels out of 80 to form a
table of sixteen orthogonal frequency hopping patterns (see 8.4.2). Each frequency hopping pattern
corresponds to a channel. The master assigns a communication channel (or channels) using the MCF (Master
Control Frame) to be described below (see 7.4). Within each communication channel which is specified by a
unique frequency-hopping pattern, the devices communicate with each other using time-division multiple
access without any other intervention of the master.
The pico-net may have up to sixteen independent simultaneous communication channels. Within each
communication channel, point-to-multipoint communication (broadcasting) is possible not to mention one-to-
one communications. Moreover, each device may switch to another communication channel other than the
current one if permitted by the master. Figure 1 shows an example of group communication in the pico-net.
The master (M) transmits a beacon signal and is communicating with only one slave (S). The other slaves are
communicating with another via other channels independently of the master.
Data are encased into the well-tailored standard units of a frame, a middleframe, and a superframe (see 8.3).
Figure 2 shows the relationship between these units. These data formats are synchronised to the master
beacon signal. To accommodate different applications in a single framework, this International Standard fixes
the length of protocol frames to 16 ms which gives a permissible level of latency in most applications.
A middleframe consists of frames. Sixteen middleframes constitute a superframe.
A frame is categorised into one of the seven kinds depending on its use: (1) a beacon frame (BF), (2) a fast
beacon frame (FBF), (3) a request control frame (RCF), (4) a master control frame (MCF), (5) an RCF
acknowledge control frame (RACF), (6) an MCF acknowledge control frame (MACF), and (7) a payload frame
(PF). All the frames except the payload frame (PF) are control frames. All the frames have an identical format
consisting of Lock Time, Preamble, Header, Message, and EoF Delimiter (see 8.2). Header is used to identify
the kind of the frame. The message field is used to convey information and data necessary for
communications (see 7.1-7.7).
4 © ISO/IEC 2010 – All rights reserved

Figure 2 — Data formats: a frame, a middleframe, and a superframe
A middleframe consists of one control frame and one or more payload frames (PF's). The middleframe starts
with a control frame whose length is fixed to 0,88 ms. The length of the middleframe is fixed to 16 ms. The
length of the payload frames varies depending on applications. The maximum number of payload frames
within a middleframe is eighteen. Carrier frequencies hop in harmony with the middleframes.
A superframe consists of sixteen middleframes and is of 256 ms. Superframes have two modes: a normal
mode and a fast synchronisation mode (see 8.3.2). A fast synchronisation mode is used for robust
synchronisation. In a fast synchronisation mode, a frame called 'fast beacon frame (FBF)' is used instead of
'beacon frame (BF)'. Two modes may be interchangeably adopted by the unit of a superframe.
For security reasons, the preamble in the frame uses Gold codes for group identification. The message field
data are also encrypted with security codes (see 9.3.2).
The MAC/PHY services and primitives will be defined and described in Section 6.
This International Standard uses the 2,4 GHz band and offers two classes of power transmission levels. Class
one is up to 100 mW and class two is up to 10 mW. As a modulation scheme, the International Standard uses
(G)FSK (see 9).
6 Interlayer service specification
This clause defines the interface between the MAC and PHY layers, and between the MAC layer and the
upper layer.
6.1 Overview
Both MAC and PHY layers conceptually have management entities, called the MLME (MAC Layer
Management Entity) and the PLME (PHY Layer Management Entity), respectively. These entities provide a
service interfaces for the layer management functions.
The PHY provides data and management services through two SAPs (Service Access Points). The PHY data
services are provided through the PD-SAP (PHY Data SAP), and PHY management services are provided
through the PLME-SAP. The DME-PLME_SAP is equivalent to MLME-PLME-SAP except that it operates
through DME rather than MLME.
The MAC provides data and management services through two SAPs (Service Access Points). The MAC data
services are provided through the MAC-SAP, and MAC management services are provided through the
MLME-SAP.
© ISO/IEC 2010 – All rights reserved 5

In order to provide correct MAC operation, each device must possess a DME (Device Management Entity).
The DME is a layer-independent entity and act under the direction of a higher-level management application.
Figure below depicts the relationships between the various management entities.

Adaptation- SAP
Device Management Entity(DME)
Adaptation Layer
MAC- SAP MLME- SAP
Media access
control sublayer MLME
(MAC)
PD- SAP MLME- PLME- SAP
PHY layer PLME
Figure 3 — The protocol model used in this International Standard
6.2 General format of management primitives
Each sublayer's specific management information is organised into the relevant Management Information
Base (MIB). Corresponding to the MIB of the PAN, the LAN/MAN contains the MIB that operates according to
the Simple Network Management Protocol (SNMP). However, since management within network is restricted
to an individual network (i.e. one network does not interfere in the management of another) the MIB is used to
define the specifications of each sublayer.
MLME and PLME are assumed to have a MIB for each sublayer, and the management primitives of the MIB
are exchanged by means of management SAPs. The manager can "GET" or "SET" the value of the MIB
attribute via the primitives. The "SET" request primitive can also trigger certain actions within the relevant
layer.
A "GET" or "SET" primitive may be expressed in the form of a request accompanying a confirm primitive.
Such primitives have the prefix MLME or PLME depending on whether the point of exchange is the MAC SAP
or the PHY SAP. DME utilizes the services provided by MLME through the MLME SAP.
In Table 1, "XX" stands for "MLME" or "PLME", and the parameters of the primitives are defined in Table 2.
Table 1 — General management primitive overview
Name Request Confirm
XX-GET 6.2.1 6.2.2
XX-SET 6.2.3 6.2.4
6 © ISO/IEC 2010 – All rights reserved

DME- PLME
-SAP
Table 2 — MLME/PLME general management primitive parameters
Name Type Valid range Description
MIBattribute Octet string Any MIB attribute MIB attribute name
MIBvalue Variable MIB value
ResultCode Enumeration SUCCESS, Result of MLME or
PLME request
INVALID_MIB_ATTRIBUTE,
READ_ONLY_MIB_ATTRIBUTE,
WRITE_ONLY_MIB_ATTRIBUTE
6.2.1 MLME-GET.request and PLME-GET.request
This primitive requests information about the relevant MAC MIB or PHY MIB. The semantics of these
primitives are as follows.
XX-GET.request (
MIBattribute
)
The primitive parameters are defined in Table 2.
6.2.1.1 When generated
DME and MLME (in the case of a PLME-GET.request) create these primitives to retrieve information from the
MAC or PHY MIB.
6.2.1.2 Effect of receipt
The relevant management entity fetches the requested MIB attribute from the database and returns the value
as the result of XX-GET.confirm.
6.2.2 MLME-GET.confirm and PLME-GET.confirm
This primitive returns the result of an information request to the relevant MAC MIB or PHY MIB. The
semantics of these primitives are as follows.
XX-GET.confirm (
Status,
MIBattribute,
MIBattributevalue
)
The primitive parameters are defined in Table 2.
6.2.2.1 When generated
DME or MLME (in the case of a PLME-GET.confirm) creates these primitives in response to an XX-
GET.request.
© ISO/IEC 2010 – All rights reserved 7

6.2.2.2 Effect of receipt
If the status is SUCCESS, these primitives return the value of the relevant MIB attribute, otherwise they return
the error code in the status field. Valid error status values include INVALID_MIB_ATTRIBUTE and
WRITE_ONLY_MIB_ATTRIBUTE.
6.2.3 MLME-SET.request and PLME-SET.request
These primitives attempt to set the value of the relevant MAC MIB or PHY MIB attribute to the specified
parameter. The semantics of these primitives is as follows.
XX-SET.request (
MIBattribute,
MIBattributevalue
)
The primitive parameters are defined in Table 2.
6.2.3.1 When generated
These primitives are created when DME or MLME (in the case o
...