Internet DRAFT - draft-jov-metropolitan-beacon-system-icd

draft-jov-metropolitan-beacon-system-icd



Internet Engineering Task Force                              J. Vogedes
Internet-Draft                                             NextNav, LLC
Intended status: Informational                           April 24, 2014
Expires: October 25, 2014



                Metropolitan Beacon System (MBS) ICD
          draft-jov-metropolitan-beacon-system-icd-01.txt





Status of this Memo



   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be
   modified, and derivative works of it may not be created,
   except to publish it as an RFC and to translate it into
   languages other than English.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed
   at http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 25, 2014.



Copyright Notice





Vogedes                Expires October 25, 2014                [Page 1]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   Copyright (c) 2014 IETF Trust and the persons identified as
   the document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust.s Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date
   of publication of this document. Please review these
   documents carefully, as they describe your rights and
   restrictions with respect to this document.

   This document may not be modified, and derivative works of it
   may not be created, except to format it for publication as an
   RFC or to translate it into languages other than English.



Abstract



This document describes the air interface of the Metropolitan Beacon
System (MBS) system.

MBS provides a high precision, reliable, consistent positioning system
indoors and in urban canyons, where GNSS solutions are degraded or denied.

In addition to the high 2-D accuracy, the MBS system architecture also
provides for high resolution and accuracy in the vertical dimension, with
the aid of embedded sensors.

MBS technology provides a very fast time to first fix (TTFF), on the order
of ~6 seconds under cold start conditions.

Similar to GNSS, MBS technology allows computation of the location on the
device without any network dependence thus enabling a wide variety of
standalone applications.


Table of Contents


   1. Introduction...................................................4
   2. Conventions used in this document..............................4
   4. MBS M1 Signal Structure........................................5
      4.1. MBS M1 Signal Generation..................................5
   A timing view of the data that is being sent at the output of
   the XOR gate is in the accompanying pdf document..................6


Vogedes                Expires October 25, 2014                [Page 2]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


      4.2. Spectral Characteristics..................................6
      4.3. MBS Signal Temporal Characteristics.......................7
      A sample of the slotted mode MBS signal transmission is
      shown in the accompanying pdf document.........................7
   5. Databurst Format...............................................9
      5.1. Slot Structure............................................9
      5.2. Error-correcting code and CRC check......................10
      5.3. Modulation...............................................12
      5.4. Packet Types . MAC Layer.................................14
         5.4.1. Overall Packet Structure............................14
         5.4.2. Packet Structure for Packet Type 1 (Full
         Trilateration Information).................................16
            5.4.2.1. Descriptions of the fields of packet type 1....17
               5.4.2.1.1. Latitude..................................17
               5.4.2.1.2. Longitude.................................17
               5.4.2.1.3. Altitude..................................17
               5.4.2.1.4. Tx Correction.............................17
               5.4.2.1.5. Tx Quality................................17
               5.4.2.1.6. Pressure..................................18
               5.4.2.1.7. Temperature...............................18
               5.4.2.1.8. Weather Information (Optional)............18
      5.5. Packet Structure for Packet Type 2 (Tx ID and GPS
      time along with Partial Trilateration Info)...................19
         5.5.1. Descriptions of the fields of packet type 2.........20
            5.5.1.1. Transmitter ID.................................20
            5.5.1.2. Tx Correction..................................20
            5.5.1.3. Pressure, Temperature, and Weather info........20
            5.5.1.4. GPS time . Week number & TOW...................21
            5.5.1.5. MBS time offset relative to GPS................21
            5.5.1.6. Slot Index.....................................21
            5.5.1.7. UTC time offset from GPS.......................22
      5.6. Additional Packet Types..................................23
      5.7. Periodicity of Packet Type Transmission..................23
      5.8. Transmit Filter Taps (at 4 samples per chip).............23
      5.9. PN Codes that may be used by MBS.........................23
   6. Security Considerations.......................................24
   7. IANA Considerations...........................................24
   8. Conclusions...................................................24
   9. References....................................................25
      9.1. Normative References.....................................25
      9.2. Informative References...................................25








Vogedes                Expires October 25, 2014                [Page 3]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014




1. Introduction



   This document and the accompanying pdf document describe the
   air interface of the Metropolitan Beacon System (MBS) system.

   MBS provides a high precision, reliable, consistent
   positioning system indoors and in urban canyons, where GNSS
   solutions are degraded or denied.

   In addition to the high 2-D accuracy, the MBS system
   architecture also provides for high resolution and accuracy
   in the vertical dimension, with the aid of embedded sensors.

   MBS technology provides a very fast time to first fix (TTFF),
   on the order of ~6 seconds under cold start conditions.

   Similar to GNSS, MBS technology allows computation of the
   location on the device without any network dependence thus
   enabling a wide variety of standalone applications.



2. Conventions used in this document



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as
   described in RFC-2119 [RFC2119].

   In this document, these words will appear with that
   interpretation only when in ALL CAPS. Lower case uses of
   these words are not to be interpreted as carrying RFC-2119
   significance.

   In this document, the characters ">>" preceding an indented
   line(s) indicates a compliance requirement statement using
   the key words listed above. This convention aids reviewers in
   quickly identifying   or finding the explicit compliance
   requirements of this RFC.




Vogedes                Expires October 25, 2014                [Page 4]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


3. High Level Architecture



   The high level system architecture diagram is represented in
   the accompanying pdf file.

   MBS beacons are an overlay network used to cover a
   metropolitan area. One implementation uses licensed wireless
   spectrum in the M-LMS band. Various components are described
   below:

   Beacon: The beacons denote the MBS beacons broadcasting the
   MBS signal. The beacons may be housed on roof tops or towers
   (typically pre-existing cell/broadcast sites), or in any
   other location deemed appropriate by the operator of the MBS
   network.

   Cell Phone: An example device that needs location information
   is shown as a cell phone under GNSS-challenged conditions
   such as urban canyons and indoors where GNSS signals from
   satellites may not be received reliably or may provide poor
   performance. The cell phones shown in the figure would be
   capable of receiving and processing MBS signals. Note that
   any device equipped to process MBS signals would work under
   these scenarios. A data or a voice connection is not required
   for a device to compute its location using the MBS
   technology.

   Location Server: In certain applications, it may be useful
   for a centralized server to compute the location with
   information it receives from the mobile because of the
   additional information that may be available to the server
   device at the time of location determination.

   GPS Satellite: Shown for illustrative purposes that it is
   blocked by buildings in an urban canyon.



4. MBS M1 Signal Structure

4.1. MBS M1 Signal Generation





Vogedes                Expires October 25, 2014                [Page 5]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   The MBS signal SHALL be generated from a PN sequence and BPSK
   spreading.  The chipping rate SHALL be 1.023 m/2 Mchips/sec,
   where m is an integer greater than or equal to 2, and the
   length of the PN sequence SHALL be 1024 n-1, where n is an
   integer greater than or equal to 1.

   The various blocks in the Signal Generator are described
   below:

   PN Code Generator: Generates binary waveforms of length 1024
   n-1. The PN code generator generates chips at the rate of
   1.023 m/2 Mchips/sec (period of each chip is 1/1.023/(m/2)
   microseconds).

   Data Generator: Collects information from sensors and other
   information such as tower Latitude, Longitude, Height (LLH)
   and other information and formats them into frames and sub-
   frames.

   FEC: Adds forward error correction. See Figure in the
   accompanying pdf file for detailed block diagram.

   Pilot/Preamble Sequence: During some periods (preamble and
   ranging periods) MBS beacons transmit a known sequence of
   bits. During the preamble, they transmit the preamble bits,
   which help with acquisition. During ranging periods, they
   transmit pilot bits, which enable long coherent integration
   to improve ranging performance.

   A timing view of the data that is being sent at the output of
   the XOR gate is in the accompanying pdf document.



4.2. Spectral Characteristics


   The transmit spectrum SHALL have the following
   characteristics:

   Tx transmission type: Spread spectrum transmission using BPSK
   spreading

   RF BW (null-to-null):   1.023m  MHz, where m = 2,3,4,...




Vogedes                Expires October 25, 2014                [Page 6]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   The Tx center frequency MAY be in any band. In the USA, one
   frequency allocation for MBS is in the LMS band, in the range
   920.773 MHz to 926.277 MHz.

   The transmit filter taps for the USA LMS band are in Appendix
   A, and the frequency response of the transmit filter is shown
   in the accompanying pdf document, for sample values of m and
   n, where m=2, n=1.



4.3. MBS Signal Temporal Characteristics
   The MBS architecture SHALL use an access scheme where each
   beacon transmits its data for a specified duration within
   each transmission period.

   A sample of the slotted mode MBS signal transmission is shown
   in the accompanying pdf document.

   System parameters:

   o  Each transmission period SHALL be 1 sec long

   o  Transmission periods SHALL be deltaT seconds apart, where
      deltaT SHALL be an integer greater than or equal to 1

   o  There SHALL be ten 100ms slots in each transmission period

   o  The MBS signal SHALL be generated from a PRN sequence and
      BPSK spreading

   o  Each transmitter SHALL be assigned:

      o One of the ten slots as its primary slot
      o One PRN code

   o Additional optional transmitter parameters include

      o A primary slot pattern
           o This is a sequence of slot indexes (each one in the
             range 1 to 10), that determine which slot the
             transmitter will transmit in successive seconds of
             transmission.
           o The sequence MAY be as basic as a simple repetition
             of the primary slot, or may be any sequence of slot



Vogedes                Expires October 25, 2014                [Page 7]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


             indexes, with each transmitter potentially having a
             different periodicity in their slot pattern.
      o Secondary slot patterns
           o Each beacon MAY have up to nine secondary slot
             patterns.
           o These MAY have the same or different PRN as the
             primary slot pattern of that transmitter, and will
             have a transmit power that SHOULD be between 0dB to
             50dB lower than the transmit power of the primary
             slot pattern.
      o Frequency offset

   o The chipping rate SHALL be 1.023 m/2 Mcps, where m is an
      integer greater than or equal to 2.
   o Each PN code SHALL have 1024n-1 chips and lasts (n+(n-
      1)/1023)/(m/2) ms.
           o Every 100ms slot includes (100 m/2)/(n+(n-1)/1023)
             PN code symbols
           o One PN code symbol must be used as a guard time
             between slots, therefore there are (100 m/2)/(n+(n-
             1)/1023)-1 PN code symbols available for ranging
             and data transmission in each 100ms.
           o For example, when m=2 and n=1, the system can fit
             100 PN code symbols in 100ms, out of which 99 are
             available for ranging and data transmission.
   o Each beacon transmits a preamble using a PN code reserved
      only for preambles.
           o Ranging slots (described in the next section) have
             a preamble of length p^R PN codes (leaving (100
             m/2)/(n+(n-1)/1023)-1-p^R PN codes for pilot
             symbols)
           o Hybrid slots (described in the next section) have a
             preamble of length p^H PN codes (leaving (100
             m/2)/(n+(n-1)/1023)-1-p^H  PN codes for pilot and
             data symbols)
   o A list of possible PN Codes used by MBS is shown in
      Appendix B.












Vogedes                Expires October 25, 2014                [Page 8]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014




5. Databurst Format
   MBS uses the concept of databursts in order to be able to
   transmit all the data required for trilateration (such as
   latitude, longitude, etc.) in a short amount of time, and
   also be able to perform long coherent integrations to enable
   high ranging accuracy. An optional implementation would be to
   divide the time available to a transmitter into ranging
   portions and data portions. During the ranging part,
   transmitters transmit pilot symbols that enable long coherent
   integration, and during the data part, transmitters transmit
   data symbols at a physical-layer rate of 1 bit per PN code
   period. An optional slot structure, implementing the above
   methodology, is presented below.



5.1. Slot Structure

   1. Separate slots for ranging and data

   o  One slot uses BPSK pilot symbols for ranging
   o  This MAY be followed by one or more slots that are hybrid
      (ranging & data slots)

   2. Use error-correcting codes & CRC for the data portions



   In general, an MBS deployment MAY have zero or more hybrid
   slots for each ranging slot. In scenarios where there are
   zero hybrid slots, receivers must obtain assistance data via
   another channel in order to perform trilateration.

   One possible implementation, for the sample scenario of
   m=2,n=1, which results in 99 PN code symbols per 100ms being
   available for ranging and data transmission, uses the
   following settings:

        o Slot structure consists of one ranging slot followed
          by two hybrid slots
             o This structure is referred to as RH1H2 and is
               depicted in the Figure in the accompanying pdf
               document



Vogedes                Expires October 25, 2014                [Page 9]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


        o Ranging slots:
             o 7 PN codes for preamble
             o 92 PN codes for pilot symbols
        o Hybrid ranging & data slots:
             o 4 PN codes for preamble
             o 14 PN codes for pilot symbols
             o 81 PN codes for data transmission using BPSK at 1
               PN code/symbol

   Using the RH1H2 slot structure and sample implementation from
   above, MBS is able to support 102 information bits in one
   data packet. These information bits are used for transmitting
   information required for trilateration (such as Tx
   lat/long/altitude).

   In terms of alignment of above slot structure to GPS time,
   MBS physical slot 1 of the R frame (see Figure 5) starts at
   .GPS time in seconds. modulo 3 = 0, plus .GPS time offset.
   (from MBS packet type 2, described in a later section)



5.2. Error-correcting code and CRC check
   MBS SHALL use error-correcting codes to ensure operation at
   low SNRs and uses CRC to ensure that the decoded bits are
   valid. The error-correcting codes and CRC polynomials chosen
   for MBS may vary from implementation to implementation.

   The remainder of this section describes the implementation
   with the RH1H2 slot structure and the sample scenario of m=2,
   n=1, which uses a convolutional code with constraint length 7
   and a 16-bit CRC polynomial.

   A block diagram of the encoding process is shown in the
   figure in the accompanying pdf file.



   The CRC check is accomplished using a length-N(CRC) CRC code.
   The value of N(CRC) is 16, and the CRC polynomial used is
   x^16 + x^15 + x^12 + x^7 + x^6 + x^4 + x^3 + 1.

   Each of the two hybrid slots is encoded and decoded
   separately, though the CRC is common to both slots. That is,
   the transmitter takes the 102 information bits, calculates
   the 16 bits of CRC, resulting in 118 bits. It then divides


Vogedes                Expires October 25, 2014               [Page 10]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   these 118 bits into two parts of length 59 bits, and it is
   these 59 bits which are encoded and transmitted using the 81
   available PN code symbols in each hybrid slot.

   The error-correcting code used is a convolutional code. The
   code has constraint-length 7 and is a rate-1/2 code that is
   punctured to ensure that the encoded bits fit within the 81
   available PN code symbols in each hybrid slot. The
   transmitter adds 6 all-zero tail bits to the information bits
   before encoding, due to the nature of convolutional coding
   and decoding.

   The encoding process and what is described above can also be
   visualized in the figures in the accompanying pdf file.

   The encoding process for this sample scenario can be
   summarized as:

   1. Take 102 info bits as inputs

   2. Add 16 CRC bits, to end up with 118 bits

   3. Split into two groups of 59 bits (first 59 for H1 slot
   last 59 for H2)

   4. For each group of 59 bits

   a. Add 6 tail bits, to end up with 65 bits

   b. Encode using the rate 1/2 encoder, to end up with 130 bits

   c. Puncture the output of the encoder, to end up with 81 bits

   d. Interleave the above bits, and send the result to the
   modulator, to be transmitted over-the-air to the receiver.

   Encoder information:

          o Convolutional encoder of rate: 1 / 2
          o Constraint-length: 7
          o Encoder polynomials:  [171 133]       (in octal)
          o Puncturing pattern: Of the 130 encoder output bits,
             select 81, according to bpunct[k] =
             benc[idx_pass[k]],  k = 0 to 80 where

   idx_pass[] = {
   1,2,4,6,7,9,10,12,14,15,17,18,20,21,23,25,26,28,29,31,33,34,3


Vogedes                Expires October 25, 2014               [Page 11]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   6,37,39,41,42,44,45,47,49,50,52,53,55,57,58,60,61,63,64,66,68
   ,69,71,72,74,76,77,79,80,82,84,85,87,88,90,92,93,95,96,98,100
   ,101,103,104,106,107,109,111,112,114,115,117,119,120,122,123,
   125,127,128 };

      o Interleaving pattern: From the input bit sequence
        bpunct[k] where k = 0 to 80, calculate the output bit
        sequence bout[k] according to

   bout[k] = bpunct[idx_permute[k]],  k = 0 to 80

   where idx_permute is the following length-81 array:

   idx_permute[] = {

   4,21,80,65,39,35,6,32,8,47,45,25,23,76,41,16,30,7,46,11,9,51,
   2,43,71,79,69,74,50,70,78,10,62,17,60,15,13,5,68,36,27,72,75,
   40,38,54,24,52,64,58,55,20,63,59,26,67,31,49,0,56,42,61,53,66
   ,3,18,48,22,34,57,12,33,19,37,73,28,1,29,77,44,14 };

    (The receiver demodulates the signal in each slot, de-
   interleaves the resulting soft bits and passes them through
   the decoder. The receiver concatenates the output of the
   decoder from the two hybrid slots H1 and H2 and does a CRC
   check to ensure that the block of data was sent successfully)

5.3. Modulation

In ranging slots, after the preamble, MBS SHALL use BPSK
modulation to transmit (100 m/2)/(n+(n-1)/1023)-1-p(sub R) pilot
bits over the same number of PN code periods. These are the
pilot bits that enable the long coherent integration times. The
pilot bit sequence during ranging slots is described below.

In hybrid slots, after the preamble, there are (100 m/2)/(n+(n-
1)/1023)-1-p(sub H) PN code periods left in the slot. MBS uses
BPSK modulation to transmit pilot bits over a subset of these
code periods, and then uses DBPSK (differential BPSK) modulation
to transmit data bits over the remaining PN code periods. The
transmitter uses the last pilot bit as the first DBPSK data bit
so that it can maximize the number of data bits it can transmit,
even though it is using DBPSK. The pilot bit sequence is
different for H1 and H2 slots.

The pilot bit sequences for ranging and hybrid slots depend on
the MBS network configuration and MAY be in one of two modes.



Vogedes                Expires October 25, 2014               [Page 12]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


The following are the two modes for the RH1H2 slot structure for
the sample scenario of m=2,n=1 :

   Pilot Sequence Mode 1:

   Ranging (R) slot:

   0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

   H1 pilot sequence:   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

   H2 pilot sequence:   0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1



   Pilot Sequence Mode 2:

   R slot:

   1,1,1,1,1,0,1,0,1,1,0,1,0,0,0,1,1,0,1,1,0,0,1,1,1,0,0,0,0,1,0
,1,1,0,1,1,0,1,0,1,1,1,0,0,1,0,0,1,1,1,0,0,1,1,0,0,0,1,1,0,1,1,0
,0,1,0,1,1,0,0,0,1,0,0,1,1,0,1,0,0,0,0,0,1,0,1,1,1,1,1,0,1

   H1 pilot sequence:   0, 1, 0, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 0

   H2 pilot sequence:   0, 0, 1, 0, 0, 1, 0, 1, 1, 1, 0, 0, 1, 0



In all sequences above, a .0. is mapped to .-1., and a .1. is
mapped to .1. during modulation.
















Vogedes                Expires October 25, 2014               [Page 13]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.4. Packet Types . MAC Layer



   MBS supports various packet types, such as one that carries
   trilateration information and one that carries GPS time
   information. For each packet type, MBS could support
   encryption of the payload, and MBS service providers may
   choose to encrypt or may choose not to encrypt the various
   packets.

   The remainder of this section describes the implementation
   corresponding to the RH1H2 slot structure and the sample
   scenario of m=2, n=1, which is able to carry 102 information
   bits per data packet.

   The various packet types supported are listed in Table 1 (see
   accompanying pdf document for additional details).

                       Table 1: Packet types

     +------+---------------+-------------------+------------+

     | Type |    Payload    | # of payload bits | # of slots |

     +------+---------------+-------------------+------------+

     | 0    | Reserved      | TBD               | TBD        |

     | 1    | LLA, etc      | 99                | 2          |

     | 2    | TxID, etc     | 96                | 2          |

     | 3-6  | Reserved      | TBD               | any        |

     | 7    | Extensions    | TBD               | any        |

     +------+---------------+-------------------+------------+

   This section specifies how many bits are required to be
   transmitted for each field of each packet type listed above.

5.4.1. Overall Packet Structure

Since there is more than one data packet type, there is a need
for an indicator to denote which one the Rx is seeing at any
given time.


Vogedes                Expires October 25, 2014               [Page 14]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


Three bits are allocated to describe the packet type. In future
versions of MBS, extension packet types MAY be supported by
using .111. as the base packet type (to denote .more packet type
information to come.), and then have a few bits after that to
denote more packet types.

The total payload of the RH1H2 scheme is 102 information bits
per RH1H2 triplet of slots. Out of those 102 bits, 3 are for
packet type index, leaving 99 bits for the data payload and any
other framing overhead.

If some data to be transmitted is more than can be carried in
one RH1H2 packet, the Tx sends the data over more than one
packet. In that case, there is a need for a scheme to identify
how the bits from the current data packet fit into the overall
set of data bits that are to be transmitted. In order to have
unambiguous understanding by the receiver on what is being
transmitted in each data packet, the scheme is visually
presented in the accompanying pdf document.  Below are some of
the principles of the data packet structure:

      o In every packet of 102 bits, the first three bits are
        the packet type
      o For packet types 0 and 1:
           o The next 99 bits contain the main packet payload
      o For packet types other than 0 and 1:
           o The fourth bit is a reserved bit.
           o The fifth bit is the start bit, and denotes whether
             this frame begins a new packet (1) or the
             continuation of a previous packet (0).
           o The sixth bit is the stop bit, and denotes whether
             this is the last frame of a packet (1) or a
             continuation frame of a packet (0).
           o The next 96 bits contain the packet payload

Summary: 3 bits of framing overhead for packet types 0 and 1,
and 6 bits of framing overhead for packet types other than 0 and
1.











Vogedes                Expires October 25, 2014               [Page 15]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014




5.4.2. Packet Structure for Packet Type 1 (Full Trilateration
   Information)

               Table 2: Packet Info for Packet Type 1

               +-------------+-----------+----------+

               |    Field    | bit_index | num_bits |

               +-------------+-----------+----------+

               | Packet type |  1 - 3    |        3 |

               | Payload     |  4 - 102  |       99 |

               +-------------+-----------+----------+

                 Table 2: Payload for Packet Type 1

 +-------------------------+----------+-----------+------------+

 |          Field          | field_id | bit_index | num_txbits |

 +-------------------------+----------+-----------+------------+

 | Latitude                |        1 |  1 - 26   |         26 |

 | Longitude               |        2 | 27 - 53   |         27 |

 | Altitude                |        3 | 54 - 68   |         15 |

 | Tx correction           |        4 | 69 - 73   |          5 |

 | Tx quality              |        5 | 74 - 77   |          4 |

 | Pressure                |        6 | 78 - 87   |         10 |

 | Temperature             |        7 | 88 - 94   |          7 |

 | Weather info(optional)  |        8 | 95 - 99   |          5 |

 +-------------------------+----------+-----------+------------+





Vogedes                Expires October 25, 2014               [Page 16]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.4.2.1. Descriptions of the fields of packet type 1

   Individual MBS service providers SHOULD map the raw values of
   the bits for each field to a range and resolution they feel
   best meets their requirements. Below are descriptions and
   sample ranges for each field.

5.4.2.1.1. Latitude

   Latitude of the Tx antenna. Sample range: [-90, 90] degrees.

5.4.2.1.2. Longitude

   Longitude of the Tx antenna. Sample range: [-180, 180]
   degrees.

5.4.2.1.3. Altitude

   Altitude of the Tx antenna. Sample range: [-500, 9000]
   meters.

5.4.2.1.4. Tx Correction

   Tx correction is the residual timing error left over after
   the Tx adjusts its transmission to account for the various
   delays in the system, such as cable delays. The receiver
   needs to take the Tx correction into account to fine-tune the
   pseudorange estimate from each transmitter (the Tx correction
   value for a given beacon needs to be subtracted from the
   receiver time stamp of the time-of-arrival estimate for that
   beacon).

   Sample range:  [0,31] ns.

   Note: A bit sequence of all ones for the Tx Correction bit
   field denotes an invalid Tx Correction value, i.e. the
   transmitter has not been able to determine the Tx Correction
   value.

5.4.2.1.5. Tx Quality

   Each beacon transmits some bits that denote to the receiver
   some relative quality metric about that particular beacon.

   Sample range: [0, 15].




Vogedes                Expires October 25, 2014               [Page 17]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.4.2.1.6. Pressure

   The transmitter SHALL transmit pressure information to the
   receiver.

   One option is to transmit the pressure measured at the
   beacon. Another option MAY be to transmit a transformation of
   the pressure measured at the beacon. As a sample
   transformation, the transmitter MAY convert the pressure
   measured at the beacon to an estimated pressure at a
   reference altitude level.

   Sample range: [94500, 106776] Pa.

5.4.2.1.7. Temperature

   The temperature measured at the beacon, which represents
   ambient atmospheric temperature.

   Sample range: [228, 330] Kelvin.

5.4.2.1.8. Weather Information (Optional)

   Each transmitter MAY transmit some bits that denote to the
   receiver some extra information about the weather and/or
   weather equipment, to enable improved altitude calculation.

   Some examples of such information are:

               o Wind speed
               o Quality of the weather data
                  (pressure/temperature/etc)
               o Additional weather/atmospheric extensions

   Sample range: [0,31]














Vogedes                Expires October 25, 2014               [Page 18]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.5. Packet Structure for Packet Type 2 (Tx ID and GPS time
   along with Partial Trilateration Info)



               Table 4: Packet Info for Packet Type 2

              +--------------+-----------+----------+

              |    Field     | bit_index | num_bits |

              +--------------+-----------+----------+

              | Packet type  | 1 - 3     |        3 |

              | Reserved bit | 4         |        1 |

              | Start bit    | 5         |        1 |

              | Stop bit     | 6         |        1 |

              | Payload      | 7 - 102   |       96 |

              +--------------+-----------+----------+

                 Table 5: Payload for Packet Type 2

+--------------------------+----------+-----------+------------+

|            Field         | field_id | bit_index | num_txbits |

+--------------------------+----------+-----------+------------+

| Tx ID                    |        1 |  1 - 15   |         15 |

| Tx correction            |        2 | 16 - 20   |          5 |

| Pressure                 |        3 | 21 - 31   |         11 |

| Temperature              |        4 | 32 - 39   |          8 |

| Weather info             |        5 | 40 - 46   |          7 |

| GPS time - Week Number   |        6 | 47 - 56   |         10 |

| GPS time - TOW in seconds|        7 | 57 - 76   |         20 |



Vogedes                Expires October 25, 2014               [Page 19]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


| Time offset relative/GPS |        8 | 77 - 86   |         10 |

| Slot Index               |        9 | 87 - 90   |          4 |

| UTC time offset from GPS |       10 | 91 - 96   |          6 |

+--------------------------+----------+-----------+------------+

5.5.1. Descriptions of the fields of packet type 2

   Individual MBS service providers SHOULD map the raw values of
   the bits for each field to a range and resolution they feel
   best meets their requirements. Below are descriptions and
   sample ranges for each field.

5.5.1.1. Transmitter ID

   The Tx ID field MUST be a unique ID that identifies each
   transmitter within one major deployment area, such as within
   North America. With 15 bits, up to 32,768 unique transmitters
   can be identified. The Tx ID should be used, along with an
   almanac on the receiver, to extract the lat/long/height of
   each transmitter, as well as the Tx quality information for
   each transmitter.

   Sample range: [0, 2^15-1]

5.5.1.2. Tx Correction

   Tx correction is as described in Section 5.4.2.

   Sample range: [0,25] ns, 1ns resolution

5.5.1.3. Pressure, Temperature, and Weather info
   Pressure, Temperature, and Weather info are as described in
   Section 5.4.2.

   Pressure - Sample range: [94500, 106776] Pa, with 6 Pa
   resolution

   Temperature -  Sample range: [228, 329.6] Kelvin, with 0.4
   degrees Kelvin resolution

   Weather info -    Sample range: [0,124]




Vogedes                Expires October 25, 2014               [Page 20]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.5.1.4. GPS time . Week number & TOW


   This represents the GPS time of the R frame immediately
   preceding the H1/H2 frames in which this packet was carried.
   GPS time is represented as time of week (TOW) and GPS week
   number.

   TOW is the number of seconds since the beginning of the GPS
   week, which runs from zero to 604799 at the end of week. The
   TOW second count returns to zero coincident with the
   resetting of the GPS PRN codes.

   The GPS week number represents the GPS weeks (modulo 1024)
   since week 0 which started at 00:00:00 Sunday 6th January,
   1980.

   Week number -  Range: [0,2^10-1] weeks, with 1 week
   resolution

   TOW seconds - Range: [0, 604799] sec, with 1 sec resolution

5.5.1.5. MBS time offset relative to GPS



   This is the offset of MBS system time relative to GPS time.
   Note that MBS system time is always delayed relative to GPS
   time by the number of nano-seconds specified in this field
   and is expected to be a constant.

   Sample range: [0,1000] ns, with 1ns resolution.



5.5.1.6. Slot Index



   This is the physical time slot in which a transmitter is
   transmitting.

   Range: [0,9].





Vogedes                Expires October 25, 2014               [Page 21]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.5.1.7. UTC time offset from GPS


   This is the UTC time offset from GPS time. The UTC offset
   field can accommodate 63 leap seconds (six bits).

   Range: [0,63] sec, with 1 sec resolution.









































Vogedes                Expires October 25, 2014               [Page 22]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


5.6. Additional Packet Types


   Additional packets using packet type greater than 2 MAY be
   defined as required for the MBS system.



5.7. Periodicity of Packet Type Transmission



   The periodicity and the associated time offset of the
   transmission for various packet types is MBS service provider
   specific. The packet transmissions of a particular type MAY
   be staggered relative to other beacons.

   As an example, in the beacon with Tx ID 1 occupying slot 1,
   the packet with type 2 MAY be transmitted once in 30 seconds
   starting at GPS TOW second (modulo 30)=0 and packet type 0
   MAY be transmitted at all other times. Whereas, in the beacon
   with Tx ID 2 occupying slot 2,  packet type 2 may be
   transmitted once in 30 seconds starting at GPS TOW second
   (modulo 30)=3 and packet type 0 may be transmitted at all
   other times.



5.8. Transmit Filter Taps (at 4 samples per chip)



   See accompanying pdf document, appendix A.



5.9. PN Codes that may be used by MBS



   In general, any family of PN codes MAY be used for MBS. For
   example, the GPS family of Gold Codes MAY be used, as shown
   in the accompanying pdf document (Appendix B). Note that the
   G2 delay and G2 code initial state in the table are specified
   in the same way as in the GPS interface specification IS-GPS-
   200 Revision E.


Vogedes                Expires October 25, 2014               [Page 23]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


   Sample PN Codes used by MBS, based on GPS family of Gold
   Codes are shown in the accompanying pdf document.

   The .G2 delay. referred to in the table above is the delay of
   the G2 code used in the standard GPS PN Code generation of
   length 1023. In pseudocode:

     y1 = standard_gps_m_sequence1_G1;
     y2 = standard_gps_m_sequence2_G2;
        PN_code = xor(y1, circular_shift(y2,delay));



6. Security Considerations



   The MBS ICD does not itself create a security threat.



7. IANA Considerations



   There are no IANA considerations for the MBS ICD.



8. Conclusions



   Metropolitan Beacon System (MBS) consists of a network of
   terrestrial beacons broadcasting signals for positioning
   purposes. Terrestrial Beacon Systems can be designed to
   facilitate UE positioning in areas where in-orbit satellite
   based systems are most challenged, such as indoors, or in
   dense urban environments and extends UE positioning
   capabilities in these environments. In addition, MBS enables
   the delivery of an accurate UE altitude for emergency or
   commercial services.






Vogedes                Expires October 25, 2014               [Page 24]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014




9. References

9.1. Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to
             Indicate Requirement Levels", BCP 14, RFC 2119,
             March 1997.

9.2. Informative References

    [GPS ICD] IS-GPS-200, Revision D, Navstar GPS Space Segment Navigation User Interfaces, March 7th, 2006



















Vogedes                Expires October 25, 2014               [Page 25]

Internet-Draft   Metropolitan Beacon System (MBS) ICD        April 2014


Authors' Addresses

   Jerome Vogedes
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085
   jvogedes@nextnav.com

   Ganesh Pattabiraman
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085

   Arun Raghupathy
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085

   Andrew Sendonaris
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085

   Norman Shaw
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085

   Madhu Shekhar
   NextNav, LLC
   484 Oakmead Parkway
   Sunnyvale, CA  94085

















Vogedes                Expires October 25, 2014               [Page 26]