Comments on 15-03/530R1 Sg4a Technical Requirements

Comments on 15-03/530R1 Sg4a Technical Requirements

254 JanuaryFebruary, 2004 IEEE 15-0304-05300084-0000-004a

IEEE P802.15

Wireless Personal Area Networks

Project / IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Title / Comments on 15-03/530r1 SG4a Technical Requirements
Date Submitted / 04/0104/[PhR1]02/1225
Source / Colin Lanzl
Aware, Inc.
/ Voice:[+1-781-687-0578]
E-mail:[
Re:
Abstract / Comments to the technical requirements for the proposal evaluation for Study Group 4a
Purpose / This is a working document that will become the repository for the terms and definitions to be used in the selection process for a Draft Standard for TG4.
Notice / This document has been prepared to assist the IEEE P802.15. 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 acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

This is an edited version of 15-03-0530-01. A discussion of the changes suggested are provided in curly brackets and are not intended to be part of the technical requirements document. They are only provided to illuminate the reasoning behind the edits to the text.

Table of Contents

2.Introduction

3.PHY Layer Technical Characteristics summary

4.Topology

5.Bit Rate

6.Range

7.Coexistence and Interference Resistance

8.Channel Model

9.Power Consumption

10.Quality of service

11.Form Factor

Antenna

12.

13.Complexity and cost

14.Location awareness

15.Mobility

16.Compliance and or Supplements to 802.15.4 functionality

17.Regulatory matters

1. Introduction[PhR2]

This document and the Selection Criteria xxx provides the technical content for the project to develop an alternate low bit rate physical layer (alt-PHY).

{There is no need to tie the Selection Criteria document to the Technical Requirements document; in fact, there are good reasons to keep them separate. Remove the red highlighted text and add the underlined text.}

This alt-PHY shall be a supplement to the proposed IEEE 802.15.4 Standard, intended for low bit rate WPAN communication systems.. The reference model used for this alternate phy layer is the following:

Figure 1 – Reference partitioning

This document serves two purposes. It is first a summary of the application presentations from the Study Group 4a call for applications. Second it defines the fundamental requirements implied by applications and summarized in the documents

- ref. 15-03-0489-04-004a-application-requirement-analysis.xls

-ref. to be added (applications categorization by colin)15-03-0442-01-0004a-sg4a-categories-cfa-responses.doc

- The selection criteria document will guide proposers on how to respond to a call for proposals.

{Remove the first red highlighted text and replace with the correct reference. Remove the second red highlighted text for the same reason as in the introduction: the selection criteria document should not be tied to this document.}

2.Alt-PHY Layer Technical Characteristics summary

Anticipated high-level characteristics of the alt-PHY layer are summarized as follows. Location-awereness is a mandatory feature of the communication system based on the intended alt-PHY, and must be provided by the communication device itself without support of external features.The link throughput shall not exceed some tens of Kbps in most of the cases, while the form factor shall be compatible with the needs of sensor networks or RF tags applications. A crucial requirement is that power consumption must allow for self powered operating time without intervention during several months to several years. This list of requirements dictates that a new kind of communication devices must be specified, with possibly relaxed parameters on other features than the ones that are foreseen by the envisioned applications as summarized here above.

3.Topology

For all considered applications, the most common topology is either ad’hocTopologies considered have been ad-hoc, or meshed or tiered topology (possibly structured in a picocell arrangement).

{The red highlighted text seems contradictory: the most common topology cannot be three topologies. Replace with the underlined text.}

The network configuration has to be highly dynamic (no infrastructure set up, nodes inserted or removed “randomly”). Relaying of messages (intraforwarding) through nodes can be desirable or even necessary in particular for range extension. Localization of nodes is therefore a useful function to dynamically establish the routing configuration between nodes.

The most frequent application corresponds to data collection by a unique or a set of coordinated data collectors. Those data collectors may have to sustain a much higher throughput than the other nodes. They can also be used for dynamic coordination of the network (synchronization, localization, local address assignement…)

While the main communication streams are generally monodirectional from the nodes (e.g. sensors) to the data collector, bidirectional link have to be maintained (coordination and management of specific functions such as localization, commands to actuator nodes, …).

Individual node addresses must be capable of being dynamically assigned in a cell.

{I’m not as familiar with the 802.15.4 MAC as I should be: is the assignment of node addresses within a cell supported by the MAC? If not, this sentence should be removed. If address assignment is supported, make no changes to the text.}

Alternative proposal

  1. [PhR3]Nodes shall be dynamically addressable.
  2. Nodes shall be of two data relay classes*, either capable of relaying messages, or not.
  3. Relay nodes shall be of two data capacity classes*. One class is the smallest node which stores data for zero or one other nodeOne class is a node that stores and forwards data for only one other node. The other class shall be capable of storing data from more than one other node, generally much more than one.
  4. All nodes shall have position location capability. This does not imply where positions are computed, or by what means.
  5. Nodes shall be dynamically insertable into and removable from the network.
  6. Relay Nodes shall be of two connectivity classes*. One class has no WAN connection. The other does.
  7. Broadcast and multicast modes must be provided

* class definition:

Class A: no message relay, no WAN connection,

Class B: relay capability, no WAN connection

Class C: (a collector) massive relay capability and a WAN connection

[Also proposed: to add a diagram with the proposed topologies]

{Item c: relay nodes that store or forward data from zero nodes cannot be relay nodes. Replace the first red highlighted text by the underlined text.

Item f: these are actually relay node connectivity definitions. Add the underlined text.

Item g: Broadcast has an “a”.}

Q: Has the topology to be compatible with broadcasting modes?

4.Bit Rate

The bit rate is categorized the following way:

- individual link bit rate. This is related to a peer to peer link, typically between a sensor device and an information collector or between two devices (relaying of information, synchronization, mutual positioning etc…). The effective data bit rate can be very low (less than 1Kbps), is generally a few Kbps and in exceptional situation about 1 Mbps.

-aggregated bit rate. This is typically the bit rate concentrated from many sensor devices to a data collector during a short period of time (can be during specific situations when many devices need to update their information at the same time like alarm or emergency situations). The data collector must be capable of acquiring several Mbps of effective data.

{This definition of bit rate is actually the same definition applied to two different classes of devices. The individual bit rate defined is actually the link rate between Class A/B devices and anything else. The aggregate rate defined is actually the link rate between Class C devices and anything else. These classes should be included in the definition for clarity.}

Typical selected figures:

Link bit rate: 1 Kbps (class 1), 10 Kbps (class 2) at PHY-SAP.

Aggregated bit rate (data collector only): 101 Mbps at PHY -SAP.

{The aggregated bit rate of 10Mbps at the PHY-SAP seems too steep for a class C device: remove the red highlighted text and replace with the underlined text.}

Mention link budget?

The packet error rate used for this requirement is 8% (?) for XX octet frame body[PhR4]. The transmit EIRP is fixed by regulatory emission limits

Figure 1 – Reference partitioning

5.Range

The maximum distance between communicating nodes is generally 0 to 30 m[PhR5]. In some cases, mainly assets tracking, the range has to be extended to several hundreds of meters. Possibly relaying of messages could be used in such situations. In most of the cases the link data rate can be limited to a few Kbps where the range is very large, however the number of nodes is very large (up to thousands) and the data collector needs to absorb large aggregated data rate ( in sustained mode, and particularly in burst mode).

{The data rate text here has already been covered in section 4 above. Remove the red highlighted text, as it has no bearing on range.}

6.Coexistence and Interference Resistance

The devices need must be able to operate in high noise and high multipath environment (e.g. harsh factory environments).

The alt-PHY shall must be able to coexist sustain co-channel and out-of-band interference with other wireless devices that may be in close proximity, and that use part of the same bandfrom legal transmitters without significant performance impairment.

(comment: band in use not defined yet).

Both indoor and outdoor applicationscoexistence and interference scenarios have to be considered.

{Indoor and outdoor coexistence and interference is the topic of this section, not applications. Remove the red highlighted text and replace with the underlined text.}

7.Channel ModelEnvironment

It is anticipated that the channel environment will may be dramatically different from the current ones (i.e. those established for 2.4Ghz, 5Ghz, High Bit Rate UWB)[PhR6], due to the high specificities of the considered applications in term of range, environments, node density.

Outdoor environment has to be taken into account, not necessarily restricted to LOS. Large range is a common characteristic to most of the applications, specific harsh environments need to be considered, e.g. factory environment or large containers, with strong multipath effects.

{This section is really about the channel environment. Remove the red highlighted text and replace with the underlined text.}

8.Power Consumption

The device (complete communication system including alt-PHY and MAC) should consume less than some tens of mW during transmission (TX or RX part). The average power consumption shall not exceed 1 mW.

In addition, most of the applications requiremust operate while supporting a battery life of months without intervention[PhR7].

This suggestsTherefore that very efficient power saving modes need to be put in place, in particular for devices that transmit sporadically. In addition the coordination of nodes must not induce frequent wake up of nodes. These mechanisms must be supported by the alt-PHY layer.Efficient power savings modes must be supported by the alternate PHY.

What about the consequence on isochronous clock management, e.g. for localization?

{The red highlighted text seems to speak to requirements on the MAC, not the PHY. Since this is a technical requirements document on the alternate PHY, this does not belong here. A statement that the PHY will support power savings modes is fine. Remove the red highlighted text and replace with the underlined text.}

9.Quality of service

The critical factor is the reliability of the transmission, meaning that strong error correction methods need to be provided at PHY level.

Other Quality of Service parameter have a strong impact on PHY layer:

-Real time communication is required,

-latency may exist but must be controlled (jitter elimination for localization). Two critical functionalities are foreseen:

-

-- synchronization of nodes (mainly for localization),

-capability to provide fast reaction in emergency situations.

{The red highlighted text applies to MAC issues, not PHY issues. Remove it. As a side note, QoS can only be supplied at or above the MAC layer. Perhaps this section would be better entitled latency and jitter.}

10.Form Factor

The alt-PHY components should be capable of fitting into a form factor consistent with sensor and RF tag applications. The critical point is that this includes the battery and the antenna parts.

11.Antenna

The antenna form factor must be small enough to be compatible with the overall form factor (see above). The PHY characteristics (band in use) must allow for a planar or wire antenna. Omnidirectional antenna is the nominal requirement. This is due to the environment and the impossibility to predict the position of a device antenna. The antenna must be very robust.

12.Complexity and cost

Complexity should be minimal to enable mass commercial adoption for a variety of cost sensitive products. Complexity (gate count, die size) and BOM shall be minimized. The cost for a node has to be limited to 1$ or even a fraction of a $ for very large volumes of production (up to millions of chips per month). In a number of applications, the components are to be considered as throwaway after use.

The cost for a node has to be limited to 1$ [PhR8]or even a fraction of a $ for very large volumes of production (up to millions of chips per month).

13.Location awareness

This is a mandatory function in all most applications.

It can be related to precise (tens of centimeters) localization in some cases, but is generally limited to about one meter. Devices will be categorized in class a (cm resolution, class b (decimeter resolution), class c (meter resolution).

Localization awareness may result in different application such as precise positioning, localization aided routing, motion tracking (simple detection of an object in a determined area, or moving outside of this area).

This functionality must be built-in the node:

- based on message transit time measurement,

- with basic services embedded in the communication device( MAC +functions embedded into thealt-PHY) and capable of being serviced in a simple and automatic way by higher layers.

It is anticipated that the physical layer must be capable of providing excellent adequate time resolution and jitter elimination to properly exercise the localization awareness functionality, for example by providing services based on message transit time measurement.

{Why muddy the statement in section 1 about mandatory location features with the first red highlighted statement? Remove it and fix the grammar in the next sentence. }

14.Mobility[PhR9]

This is not a mandatory feature in most of the cases. However nodesNodes need to be still capable of reliably communicating when in the move (up to 10m/s), at least for tracking. It is admitted that limited communication performance (e.g. data rate) can be tolerated in such cases.

{I still completely disagree with the first red highlighted sentence. Tracking is essential in man-down, situational awareness and security applications and I believe it to be a mandatory requirement in inventory control applications. Remove the red highlighted sentence, replacing it with the underlined text.}

15.Compliance and or Supplements to 802.15.4 functionality

It is envisioned that the alt-PHY project will allow supplements to 802.15.4. In addition to the alt-PHY itself, the project may include MAC functionality[PhR10] necessary to support the selected alt-PHY (see 13 above as an example of possible specific requirement on the MAC).

16.Regulatory matters

The alt-PHY standard will comply with necessary geopolitical or regional regulations.

[PhR1]Rev 1

[PhR2]To be included: reference to or citation from the PAR

[PhR3]To be discussed during conf.call: an alternative way to express the topology requirement. More precise, but perhaps more constraining

[PhR4]Packe error rate etc… will be specified in the selection criteria doc for assessment purpose.

[PhR5]Not discussed yet.

One suggestion is to be more specific classes of devices (link distance) or systems (with relaying capability)

[PhR6]Not discussed yet.

Concern that existing channel models such as 2.4Ghz and 5Ghz, as currently specified, may apply without modification.

Comments, discussion?

However TE thinks that such an indication should exist at least as an indication for proposals that would use new channels, and incidentally to justify the current work on channel modeling.

[PhR7]Suggestion to give more precise metrics such as battery life related to number of exchanged communication bits, position fixes …

Q. from TE: is this metrics for selection criteria doc?

[PhR8]This topic has to be further discussed:

-do we use $ figures (cost only)

-do we use comparison ratio with reference solutions (e.g. Bluetooth)

-do we expand semiconductor factors

-do we categorize per applications?

[PhR9]Not discussed yet. Reflector comments are

-to replace mobility with tracking capability

-to consider it as a mandatory function

[PhR10]to be reformulated

minimum MAC functionality changes