ISO/IEC 29157:2015
(Main)Information technology — Telecommunications and information exchange between systems — PHY/MAC specifications for short-range wireless low-rate applications in the ISM band
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:2015 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.
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
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29157
Second edition
2015-07-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 2015
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved
Contents Page
Foreword .vi
Introduction .vii
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 . 6
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 . .20
6.6.1 PD-DATA.request .20
6.6.2 PD-DATA.confirm .21
6.6.3 PD-DATA.indication .21
7 MAC PDU format .22
7.1 MPDU of beacon frame (BF) .22
7.1.1 Open flag (OF, 2 bits) .22
7.1.2 MAC version (6 bits) .23
7.1.3 Address mode (ADDM, 2 bits) .23
7.1.4 PHY version (6 bits) .23
7.1.5 Frame type (8 bits) .23
7.1.6 Superframe mode control (SFMC, 2 bits) .23
7.1.7 Upper layer frame size (ULPS, 6 bits) .24
7.1.8 Source MAC address (64 bits) .24
7.1.9 Superframe counter (SFC, 4 bits) .24
7.1.10 Middleframe counter (FC, 4 bits).24
© ISO/IEC 2015 – All rights reserved iii
7.1.11 Hopping sequence (32 bits) .24
7.1.12 Beacon frequency table (BFT, 16 bytes) .24
7.1.13 Upper layer data (16 bytes).24
7.1.14 TCRC16 (16 bits), MCRC16 (16 bits) .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) .25
7.2.3 Address mode (ADDM, 2 bits) .25
7.2.4 PHY version (6 bits) .25
7.2.5 Frame type (8 bits) .25
7.2.6 Superframe mode control (SFMC, 2 bits) .25
7.2.7 Upper layer frame size (ULPS, 6 bits) .26
7.2.8 Source MAC address (64 bits) .26
7.2.9 Superframe counter (SFC, 4 bits) .26
7.2.10 Middleframe counter (SC, 4 bits) .26
7.2.11 Hopping sequence (32 bits) .26
7.2.12 Beacon frequency table (BFT, 16 bytes) .26
7.2.13 Upper layer data (16 Bytes) .26
7.2.14 TCRC16 (16 bits), MCRC16 (16 bits) .26
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) .27
7.3.4 PHY version (6 bits) .27
7.3.5 Frame type (8 bits) .27
7.3.6 Upper layer frame size (ULPS, 6 bits) .27
7.3.7 Source MAC address (64 bits) .27
7.3.8 Destination MAC address (64 bits) .27
7.3.9 Upper layer data .28
7.3.10 TCRC16 (16 bits), MCRC16 (16 bits) .28
7.4 MPDU of master control frame (MCF) .28
7.4.1 Open flag (OF, 2 bits) .28
7.4.2 MAC version (6 bits) .28
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 (ULPS, 6 bits) .28
7.4.7 Source MAC address (64 bits) .28
7.4.8 Destination MAC address (64 bits) .29
7.4.9 Upper layer data .29
7.4.10 TCRC16 (16 bits), MCRC16 (16 bits) .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) .30
7.7.1 Open flag (OF, 2 bits) .30
7.7.2 MAC version (6 bits) .30
7.7.3 Address mode (ADDM, 2 bits) .30
7.7.4 PHY version (6 bits) .30
7.7.5 Frame type (8 bits) .30
7.7.6 Upper layer frame size (ULPS, 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
7.7.10 TCRC16 (16 bits), MCRC16 (16 bits) .30
8 MAC functional description .31
8.1 General description .31
8.2 System state diagram .32
8.3 Protocol structure .34
iv © ISO/IEC 2015 – All rights reserved
8.3.1 Middleframe structure .35
8.3.2 Superframe structure .35
8.4 Frequency operation .37
8.4.1 Frequency hopping control .37
8.4.2 Frame frequency mapping .37
8.4.3 Frequency diversity and time diversity .38
8.4.4 Orthogonal frequency offset .38
8.4.5 Frequency selection .38
9 PHY specification .41
9.1 General requirements .41
9.1.1 Operating frequency range .41
9.1.2 Frequency assignment .41
9.1.3 Frequency synthesizer stabilisation time .41
9.1.4 Frequency synthesizer turn off time .41
9.2 PHY protocol data unit (PPDU) format .42
9.2.1 Lock time .42
9.2.2 Preamble .42
9.2.3 Header (48 bits) .43
9.2.4 Message.43
9.2.5 EoF delimiter .43
9.3 Modulation and codes .43
9.3.1 Modulation .43
9.3.2 Codes .44
9.4 Transmitter specification .45
9.4.1 Pulse shaping filter .45
9.4.2 Transmitter power spectrum mask .45
Annex A (informative) Pico-net Light-weight Architecture Security (PLAS) .46
© ISO/IEC 2015 – All rights reserved v
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.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
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.
Details of any patent rights identified during the development of the document will be in the Introduction
and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 6,
Telecommunications and information exchange between systems.
This second edition cancels and replaces the first edition (ISO/IEC 29157:2010), which has been
technically revised.
vi © ISO/IEC 2015 – All rights reserved
Introduction
This International Standard is the revision of ISO/IEC 29157. This International Standard was established
to provide a unified platform for services of data rates up to 1 Mbps: control data, voice, audio, and
video. The purpose of the revision is to accommodate the advancement of technology for higher-quality
services in the mobile applications.
The direction of the revision is three-fold: to enhance throughput, to facilitate co-existence with other
technologies such as time-division LTE (long term evolution) and WiMAX II, and to increase data rate.
For the higher throughput, the length of the preamble of the payload frames is made variable up to the
user’s need (see 9.2.2). For the co-existence, the duration of the middle frames is reduced to 4 ms from
16 ms to make align with those of the other technologies (see 8.3). With the shorter middleframes, the
International Standard does not only harmonise with other technologies, but also attains advantages of
shorter communication delay and less paring time. To increase the data rate, the message part of the payload
frames may be modulated with QPSK. The modulation format is indicated by the ‘PHY version’ of the header
(see Clause 7 and 9.3). With the addition of the new option, the data rate can be increased to 2 Mbps. In
addition, to protect communications against security challenges due to the loss of protection provided by
wires, this International Standard provides the optional security mechanism (See 9.3.2 and Annex A).
© ISO/IEC 2015 – All rights reserved vii
INTERNATIONAL STANDARD ISO/IEC 29157:2015(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 documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9798-3, Information technology — Security techniques — Entity authentication — Part 3:
Mechanisms using digital signature techniques
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 1 to entry: Sixteen middleframes constitute a superframe.
© ISO/IEC 2015 – All rights reserved 1
3.7
superframe
bigger frame consisting of sixteen middleframes
Note 1 to entry: 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 1 to entry: 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 1 to entry: Either an open or a closed code may be applied.
4 Abbreviated terms
The following acronyms are used in this International Standard.
AARQF authentication access request frame
AARSF authentication access response frame
ACCF authentication capabilities announcement frame
ADDM address mode
BF beacon frame
BPSK binary phase shift keying
DME device management entity
FBF fast beacon frame
FSK frequency shift keying
GAPF general authentication process frame
GFSK Gaussian frequency shift keying
GKAP group key authentication protocol
GTK group temporal key
ISM industrial, scientific, and medical
LSAP light-weight shared-key authentication protocol
2 © ISO/IEC 2015 – All rights reserved
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
PDU protocol data unit
PF payload frame
PHY physical layer
PLAS pico-net light-weight architecture security
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
PTK pairwise temporal key
QPSK quadrature phase shift keying
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 2 Mbps or less.
To minimise implementation effort, it assumes the use of off-the-shelf RF components for the ISM band.
© ISO/IEC 2015 – All rights reserved 3
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).
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 Interna tional
Standard fixes the length of protocol frames to 4 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
4 © ISO/IEC 2015 – All rights reserved
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 control frames have
an identical format consisting of Lock Time, Preamble, Header, Message, and EoF Delimiter (see 8.2).
The payload frame is used to carry user’s data. Unlike the control frames whose preambles are fixed,
the length of the preamble of the payload frame is variable to enhance the data throughput (see 9.2.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 to7.7).
,
,
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
4 ms. The length of the payload frames varies depending on applications. Carrier frequencies hop in
harmony with the middleframes.
A superframe consists of sixteen middleframes and is of 64 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 Clause 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 and QPSK (see 9.3).
In addition, this International Standard protects the communications from the security challenges due
to the lack of protecting wires. Eavesdroppers may overhear data exchanges not intended for them,
whereas imposters may send forged data not using its own identity, may replay previously transmitted
data, and may transmit modified data captured from a previous transmission. In order to solve these
issues, This International Standard also provides the security mechanism which the user can choose to
implement (See 9.3.2 and Annex A).
6 Interlayer service specification
This Clause defines the interface between the MAC and PHY layers, and between the MAC layer and
the upper layer.
© ISO/IEC 2015 – All rights reserved 5
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.
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.
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.
6 © ISO/IEC 2015 – All rights reserved
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
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
)
© ISO/IEC 2015 – All rights reserved 7
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.
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
paramete
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...