How to start with Sigfox Atlas?

First, if you are looking for an existing solution, you should choose one in the Partner Network.

If you want to design your own device, you must - first of all - identify the right location technology(ies) for the use case (GPS, WiFi, Sigfox Network only, etc). The 2 questions below (to ask to yourself or your user) should help you to define the right solution:

1. In which kind of environment(s) do you need to geolocate these assets ? 

• Outdoors, in rural or (far) remote areas > you'll need a long range geolocation solution, such as GPS and/or the Sigfox Network location.
• Outdoors, in urban or industrial areas > you'll need a technology suitable for dense environments, such as WiFi.
• Indoors, in public space/ venues (airports, shopping mall, etc) > the WiFi is also the most suitable for these areas - RTLS (Real Time Location Systems) can be also depending on your capacity to deploy an infrastructure in these sites.
• Indoors, in your private premises (your factory or building) > WiFi or RTLS solutions can work.
• Indoors, in private premises which are not yours (your customer or supplier factory or building) > WiFi or RTLS solutions, depending on your capacity to deploy an infrastructure in these sites.

2. What is the level of precision that you need? 

• City level > the Sigfox Network location is enough.
• Premise/ venue level > the WiFi is enough.
• Within a premise/ venue level > the RTLS solutions works well on that case.

If the Sigfox Network location and/or WiFi Positioning match with your use case, you can go with Atlas services:

• If Atlas Native fits with your use case, you don’t need to do anything on the device side. 
• If you choose Atlas WiFi, you'll find below the guidelines for the hardware and protocol for the payload format.

Guidelines for WiFi device hardware  

The device hardware must embed at least Sigfox and WiFi chipset or modules. Some guidelines regarding the WiFi component: 

• It is better to implement a WiFi chipset or module compatible with our WiFi protocol specification to increase the chance to collect (or sniff) MAC@ (the MAC address is the unique ID of a WiFi access point).
• If the device only uses WiFi chipset in sniffing mode (Rx only), there will be no need for TA certification.  
• WiFi antenna performance is critical and will have a high impact on the chance to sniff MAC@.
• For devices using modules already embedding a WiFi antenna, it is important to follow the module implementation guidelines to maximize the device radiated performance. 
• For devices with a dedicated antenna implementation, it is important to design the antenna with care and to check that the device radiated performance are high enough.  

Specification for WiFi device payload format

The device firmware should integrate the payload encoding specification and format for WiFi:

1. Collect MAC@

[SyRS_WIFILOC_001] Device shall be able to sniff all WIFI access points around it and collect the MAC address of each WIFI access point detected.

[SyRS_WIFILOC_002] Device MUST collect MAC addresses which: 

• Are from beacon frames or probe response frames (only Wifi Access Point mac address MUST be returned).
• Are not part of an ad hoc Wifi network.
• Are of type "Unicast" (LSB bit of 1st byte MUST be 0).
• Are not a reserved mac address: 00:00:00:00:00:00, FF:FF:FF:FF:FF:FF, … 

[SyRS_WIFILOC_003] Device MUST select up to two MAC addresses by filtering and prioritizing them according to rules. There are no global absolute rules which fit all business cases, so rules should be set and executed according to the forecasted devices business case. It is recommended that rules priorities and rules execution flag can be set through a configuration downlink message. 

By default, to maximize the WIFI location success rate, the following rules are recommended (by decreasing priority order):

• MAC address of type globally unique (second bit of 1st byte is 0 - see Figure 3‑3: MAC Address Format)
• Do not correspond to a mobile access point: exclude SSID containing "android", "phone", "samsung", "huawei" (case insensitive comparison). List is not exhaustive, and MUST be adapted to countries deployed
• Have not an empty SSID.
• MAC address with the strongest RSSI. 

Other custom rules which could be implemented are for instance:

• SSID in a custom whitelist or matching a pattern
• SSID not in a custom blacklist, or not matching a pattern
• Other condition on the SSID
• Other condition on the mac@ (specific OUI preferred, etc...)

As only 2 MAC addresses are used, the selection of the proper ones is critical to obtain the maximum success for the mac address geolocation resolution.

 2. Serialize and send WIFI location payload

[SyRS_WIFILOC_004] WIFI location messages shall be sent in UPLINK message of U-Procedure (Unidirectional Procedure – UL) or B-Procedure (Bidirectional Procedure). 

[SyRS_WIFILOC_005] Device shall send up to two MAC addresses selected according criteria defined above in 12-byte payload and shall comply with the format defined in Figure 3‑4: Wifi Location Payload Format:

• Parameter 1: MAC address 1
• Parameter 2: MAC address 2

[SyRS_WIFILOC_006] If only one MAC address corresponding to the criteria defined in sub-section 3.1 is sniffed by the device, the MAC address shall be sent in the first parameter of WIFI payload, the second one shall be NULL (00:00:00:00:00:00). 

[SyRS_ATLASWIFI_007] (deprecated, replaced by SyRS_WIFILOC_008) 12-Byte payload shall be not used by Device to send other type of data. 12-Byte payload is reserved to transmit ATLAS WIFI payload.

[SyRS_WIFILOC_008] For a device which has the WIFI location service provisioned, 12 Byte payload will be interpreted by Sigfox cloud according to the values of the 2 1st bits (LSB) of the 1st byte.
NB: this is not a distinct header field, as for a Wifi payload these 2 bits are part of the 1st MAC address.

The provisioning of both Atlas services must be done in the contract before its activation on the Sigfox Cloud portal (back end). 

Follow these steps to provision Atlas services on a new contract: 

• Open the order   
• Click on [Create Contract] 
• Enter a name for the contract 
• Select the correct client 
• Optional: decide whether you want to set an end date for the contract 
• Optional: decide whether you want to restrict the number of tokens applicable to the contract  
• Select “Atlas Native” or “Atlas WiFi” (available on January 1st 2020) 
• Save the contract. 

Once the Atlas service has been provision in your contract, you just need to follow the same steps than for the activation of your tokens in the back end. The availability of Atlas is mentioned in the Device Type section (“geoloc : yes”).