We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Data.Location - FIWARE Forge Wiki

FIWARE.OpenSpecification.Data.Location

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Data.Location
Chapter Data/Context Management,
Catalogue-Link to Implementation [ <N/A>]
Owner Thales Alenia Space, Tanguy Bourgault


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Copyright

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) [1] to understand the rights to use these specifications.

Overview

The Location Platform provides location-based services for two types of users:

  • Third-party location clients
Third-party location clients can interact with the location platform using the Mobile Location Protocol (MLP, [2]) interface or RESTful Network API for Terminal Location ([3]) both standardized by Open Mobile Alliance (OMA, [4]).
These interfaces facilitate many services to retrieve the position of a compatible target mobile terminal for various types of applications, ranging from single shot location retrieval to area event retrieval (geo-fencing).
The target mobile terminal position is retrieved using Assisted Global Positioning System (AGPS), WiFi and Cell-Id positioning technologies intelligently triggered depending on end-user environment and location request content (age of location, accuracy, etc.).
  • Mobile end-users
When an end-user searches for its position using a compatible terminal via any kind of application requiring location information, the terminal connects to the location platform to exchange assistance data in order to compute or retrieve its position, as negotiated between the terminal and the platform.
Moreover, some applications on the compatible terminal may include the sharing of location information with external third-parties, including other end-users.
Such service relies on another OMA standard, called Secure User Plane (SUPL, [5]).

In both scenarios, the target handset to localize must comply with the following requirements:

  • 3G capable
  • Wi-Fi optional
  • Be equipped with an assisted GPS chipset
  • Support Secure User Plane (SUPLv2) stack : No mobile in commercial market are implemented yet the v2 protocol version (only v1)

Target usage

The Location GE in FI-WARE targets any third-party application (GEs in FI-WARE, or any complementary platform enabler) that aims to retrieve mobile device positions and area events. The Location GE is based on various positioning techniques such as A-GPS, Wi-Fi and Cell-Id intelligently triggered whilst taking into account the end-user privacy. Note that the location retrieval from the end-user itself is out of scope for FI-WARE.

This GE addresses issues related to Location of mobile devices in difficult environments such as urban canyons and light indoor environments where the GPS receiver in the mobile device is not able to acquire weak GPS signals without assistance. In more difficult conditions like deep indoor, the Location GE selects other positioning techniques like Wi-Fi to locate the end-user. It therefore improves localization yield, which enhances the end-user experience and the performance of applications requesting the position of mobile devices.

To cope with the lack of SUPLv2 commercial handsets, the location GE now includes a fleet simulation tool that simulates multiple mobile devices moving across routes or staying static. The fleet and each simulated device can be managed via a RESTful interface in order to fulfill demo requirements, as requested by UC projects.

Last but not least, the Location GE is compatible with an Android application being developed by TAS for FI-WARE (required Android version is version 2.3.3 minimum). Such application does not replace a real SUPLv2 stack but aims at demonstrating the features of the Location GE with a real handset. The architecture of such application is out of scope for this document but it is important to say that the architecture presented in the next sections addresses the interface requirements.

Basic Concepts

Third-party location services

Services provided for third-party location clients are standardized under the so-called "network-initiated" procedures, since the location request is established somewhere from an application on the mobile operator or external network. Such an external network can be the Internet, since both MLP and NetAPI Terminal Location protocols are HTTP based. Please note that those services require SUPL interface towards the compatible terminal, which is based on TCP/IP.

The following MLP services are supported by the location platform:

  • Synchronous and asynchronous Standard Location Immediate Service, which provides immediate location retrieval of a target terminal for standard and emergency LBS applications,
  • Triggered Location Reporting Service, which facilitates the retrieval of periodic location or event reports from a target terminal in order to track an end-user using reported positions or reported events, such as specific zone entry.

Trigger service requires SUPL V2 interface on terminal.

Similar services are available on the NetAPI Terminal Location interface with limited functionality:

  • Location Query: provides immediate location retrieval of a target terminal,
  • Periodic Notification Subscription: facilitates the retrieval of periodic location reports from a target terminal,
  • Area (Circle) Notification Subscription: facilitates the retrieval of area event reports from a target terminal (geofencing).

Periodic and Area (Circle) Notification Subscription requires SUPL V2 interface on terminal.

Access control and privacy management

Fortunately, not all applications can access to these location services. Strong access control and privacy management rules are applied to authorize a third-party to localize a particular end-user terminal. Each location request contains client credentials (login and password) and a service identifier. These values are used by the Location GE to ensure that the correct credentials are provided and that the requested service belongs to this client. Moreover, many service parameters (stored in Location GE database) are used to accept location requests or not. For example, location requests are filtered based on service status (active or barred), type of request (single/tracking/emergency/all), level of accuracy (low/medium/high), etc. Lastly, end-user parameters (stored in Location GE database) are checked to ensure that the end-user consents to be localized by the requested service. For example, an end-user can authorize a specific service to localize him permanently, once or on selected time windows. The end-user can also override service parameters, such as level of accuracy to limit this service to Cell-ID positioning.

Mobile end-user services

Services provided for mobile end-users are standardized under the so-called "set-initiated" procedures, since the location request is established by the SUPL Enabled Terminal (SET) on behalf of the end-user launching the application requiring location information.

The following set-initiated services are supported by the location platform, however not exposed to FI-WARE developers since rely on more complex protocols (TCP/ASN.1) than network-initiated services that expose a simple RESTFul API.

  • Standard location request: the SET requests its actual position, for example to be displayed on a map.
  • Location request with transfer to third party: the SET requests its actual position and requests it to be sent to a third-party, based on the third-party information (credentials) provided. This feature is mainly used for social networks.
  • Periodic trigger: the SET requests on a periodic basis its actual position, for example for navigation purposes.

Location request with transfer to third party and Periodic trigger requires SUPL V2 interface on terminal.

Fleet Simulation

The fleet simulation tool is used to demonstrate the Location GE features. It is not part of the Location GE core engine but rather stubs the SUPLv2 interface to simulate the behavior of a real handset moving across routes or staying static.

A RESTful interface is available to manage the fleet and each single simulated device which can be found at the following URL: [6].

Based on the simulated position, the Location GE responds to location requests with the most updated position of the simulated mobile. This facilitates the demonstration of single location retrieval, periodic tracking and geofencing use cases.

Interfaces and data model

Location GE

The following diagram illustrates the interfaces previously presented:

File:Concept.gif


The following services are the grounds of the Location GE:

  • MLP service: made of an HTTP stack, it processes MLP compliant requests and after authorization of such request, it triggers the SUPL service to establish communication with the target handset (SMS) to retrieve location or events depending on the content of the request. Such request is encoded in XML format fully specified in MLP standard.
  • NetAPI Terminal Location service: similar to MLP agent, it decodes HTTP requests using RESTful procedures and once authenticated triggers the establishment of a SUPL connection with the target handset (SMS) for similar services to MLP.
  • SUPL service: made of a TCP stack, this server is used both to establish communication with a target handset (SMS) and receive connection from the handset. The SUPL service implements SUPL standardized procedures based on ASN1. Such procedures include single shot location retrieval and triggers used for periodic and area event tracking. Such interface is also used to exchange GPS assistance data via the 3GPP RRLP protocol encapsulated in the SUPL payload.

The mySQL internal database, shared between all services, contains the following data:

  • Network cell information: cell identifiers associated with cell mast position and coverage radius to be currently provided by Telco. A dynamic provisioning is planned for future FI-WARE releases in order to build this database with GPS location and cell information retrieved from the SET.
  • Third-party information: third-party account credentials and settings.
  • Third-party location services information: contains many parameters, including level of authority (lawful/standard), authorized level of accuracy (low/high), type of location authorized (standard/emergency/tracking), flow control parameters.
  • User information: contains many parameters, including friends list, global settings for authorizing localization and position caching of all location services.
  • User privacy policy: overlays service settings for a specific end-user. Many parameters are also available, including service authorization (permanent/one-shot/time-based), position-caching authorization.
  • User position cache: if activated in user privacy policy, each actual position retrieved is stored locally in the location platform database. This is mainly used by third-party location services that do not need necessarily a refreshed location.

The provisioning interface of such database is currently not exposed to FI-WARE developers, access to the database is reserved to Location GE administrators.

Fleet Simulation Tool

The Fleet Simulation Tool illustrated on the above diagram is a SUPLv2 client that has the ability to simulate movement and return associated positions and geofencing events. Its structure is shown below:

File:Fleet Architecture.gif


This simulation tool is composed of:

  • Mobile Simulation Engine, which can be controlled via a dedicated RESTful interface in order to interact with a specific simulated handset. The services available on this interface range from adding/getting/deleting a path and starting/stopping the movement of the handset on the current path. The path is defined as a list of vertices with a context that includes identity and movement parameters.
  • Scenario Management module also manageable via a dedicated RESTful interface. It offers the ability to select a predefined fleet simulation scenario and start/pause/stop that scenario.
  • SUPL client module, which in charge of handling SUPLv2 responses based on simulated terminal positions and SUPLv2 location requests. It supports single shot location retrieval, periodic reporting and geofencing events.

Main Interactions

MLP services

The MLP request processing is illustrated on the below diagram. Before processing the location transaction, various checks are performed to parse and authorize the request based on client credentials, service and end-user settings as presented before:

File:MLP processing.gif


The following sub-sections present the XML structure of MLP requests and their associated responses.

Access control and privacy management

Each of the incoming MLP requests are checked for authentication and authorization before localizing the end-user. The following example shows the MLP request header:

<?xml version="1.0" ?>
<svc_init ver="3.2.0">
  <hdr ver="3.2.0">
    <client>
      <id>login</id>
      <pwd>password</pwd>
      <serviceid>servicename</serviceid>
    </client>
    <requestor type="MSISDN">
      <id>33612345680</id>
    </requestor>
  </hdr>
  <!-- Location request -->
</svc_init>

The <client/> section contains the elements required for authentication and facilitates the retrieval of the third-party location service requested. The <requestor/> element is used for checking the friends list of the target end-user, identified by the MSISDN. The <serviceid/> and target end-user MSISDN are utilized to check the end-user privacy policy previously presented.

Standard Location Immediate Service

This service facilitates the location retrieval of the handset on a one-shot basis. The sequence of messages is illustrated below:

File:SLIR.gif

It is triggered by an MLP SLIR request, as follows:

<slir ver="3.2.0" res_type="SYNC">
    <msids>
      <msid type="MSISDN">33612345678</msid>
      <msid type="MSISDN">33612345679</msid>
    </msids>
    <eqop>
      <hor_acc>1000</hor_acc>
    </eqop>
    <loc_type type="CURRENT_OR_LAST" />
  </slir>

This request triggers a standard network-initiated SUPL transaction towards the handset. Once the handset location is retrieved, the Location Platform responds with a SLIA response, containing the position of the target end-user:

<slia ver="3.2.0" >
  <pos pos_method="CELL">
    <msid type="MSISDN">33612345678</msid>
    <pd>
      <time>20020623134453</time>
      <shape>
        <EllipticalArea>
             <coord>
              <X>50.445668</X>
              <Y>2.803677</Y>
             </coord>
             <angle>0.0</angle>
             <semiMajor>707</semiMajor>
             <semiMinor>707</semiMinor>
             <angularUnit>Radians</angularUnit>
        </EllipticalArea>
      </shape>
      <alt>0</alt>
      <alt_unc>707</alt_unc>
    </pd>
  </pos>
  <pos>
    <msid>33612345679</msid>
    <pd>
      <time>20020623134454</time>
      <shape>
        <EllipticalArea>
             <coord>
              <X>50.445668</X>
              <Y>2.803677</Y>
             </coord>
             <angle>0.0</angle>
             <semiMajor>707</semiMajor>
             <semiMinor>707</semiMinor>
             <angularUnit>Radians</angularUnit>
        </EllipticalArea>
      </shape>
      <alt>0</alt>
      <alt_unc>707</alt_unc>
    </pd>
  </pos>
</slia>

Emergency Location Immediate Service

This service facilitates the location retrieval of the handset on a on-shot basis for emergency purposes. It is triggered by an MLP EME_LIR request instead of a SLIR, as follows:

<eme_lir ver="3.2.0">
  <msids>
    <msid type="MSISDN">33612345678</msid>
  </msids>
  <loc_type type="CURRENT_OR_LAST" />
</eme_lir>

This request triggers an emergency network-initiated SUPL transaction towards the handset. Once the handset location is retrieved, the Location Platform responds with an EME_LIA response instead of a SLIA, containing the position of the target end-user:

<eme_lia ver="3.2.0">
  <eme_pos>
    <msid type="MSISDN">33612345678</msid>
    <pd>
      <time>20020623134454</time>
      <shape>
        <EllipticalArea>
             <coord>
              <X>50.445668</X>
              <Y>2.803677</Y>
             </coord>
             <angle>0.0</angle>
             <semiMajor>707</semiMajor>
             <semiMinor>707</semiMinor>
             <angularUnit>Radians</angularUnit>
        </EllipticalArea>
      </shape>
      <alt>0</alt>
      <alt_unc>707</alt_unc>
    </pd>
  </eme_pos>
</eme_lia>

Triggered Location Reporting Service

This service facilitates the periodic location or event-based reports retrieval from the handset. The message sequence is illustrated below:

File:TLRR.gif

It is triggered by an MLP TLRR request, as follows:

<tlrr ver="3.2.0">
  <msids>
    <msid type="MSISDN">33612345678</msid>
  </msids>
  <interval>00003000</interval>
  <start_time>20021003112700</start_time>
  <stop_time>20021003152700</stop_time>
  <qop>
    <hor_acc>100</hor_acc>
  </qop>
  <pushaddr>
    <url>http://location.application.com</url>
  </pushaddr>
  <loc_type type="CURRENT"/>
</tlrr>

The Location Platform acknowledges the request with a TLRA when the SUPL transaction confirmed that the target SET received all trigger parameters and has exchanged eventually assistance data if needed. The TLRA only contains a unique transaction identifier that can be used to map trigger reports with the original location request:

<tlra ver="3.2.0">
  <req_id>25293</req_id>
</tlra>

Each location/event report returned by the handset via SUPL is returned in a TLREP, as follows:

<tlrep ver="3.2.0">
  <req_id>25293</req_id>
  <trl_pos trl_trigger="PERIODIC">
    <msid type="MSISDN">33612345679</msid>
    <pd>
      <time>20020623134453</time>
      <shape>
        <EllipticalArea>
             <coord>
              <X>50.445668</X>
              <Y>2.803677</Y>
             </coord>
             <angle>0.0</angle>
             <semiMajor>707</semiMajor>
             <semiMinor>707</semiMinor>
             <angularUnit>Radians</angularUnit>
        </EllipticalArea>
      </shape>
      <alt>0</alt>
      <alt_unc>707</alt_unc>
    </pd>
  </trl_pos>
</tlrep>

NetAPI Terminal Location services

As stated before, the NetAPI Terminal Location interface provides similar services to MLP with some limitations. The main interactions between third-party application and Location GE are presented in this chapter. XML location request content type is supported in current FI-WARE release. Support of JSON and url-form-encoded content types will be soon added as specified in Location GE API. The following section present XML content type.

Location Query

The Location Query facilitates the retrieval of the current location of a target terminal. The message sequence is illustrated on the following diagram: Image:Location Query.gif

The Location GE receives an HTTP GET request including many parameters that are used for the authentication of the third-party application and quality of position parameters that define the type of location requested. The full list of supported parameters is provided in the API Specifications (see references). An example of a request is provided below:

GET /location/v1/queries/location?requester=test:test&address=33611223344&requestedAccuracy=50&acceptableAccuracy=60
 &maximumAge=100&tolerance=DelayTolerant HTTP/1.1
 Accept: application/xml
 Host: example.com

Once authenticated, the location request triggers a SUPL transaction towards the target handset to retrieve its location. When retrieved the following content is returned:

 HTTP/1.1 200 OK
 Content-Type: application/xml
 Content-Length: nnnn
 Date: Thu, 02 Jun 2011 02:51:59 GMT

 <?xml version="1.0" encoding="UTF-8"?>
 <tl:terminalLocationList xmlns:common="urn:oma:xml:rest:netapi:common:1"  xmlns:tl="urn:oma:xml:rest:netapi:terminallocation:1">
  <tl:terminalLocation>
   <tl:address>33611223344</tl:address>
   <tl:locationRetrievalStatus>Retrieved
   </tl:locationRetrievalStatus>
   <tl:currentLocation>
    <tl:latitude>49.999737</tl:latitude>
    <tl:longitude>-60.00014</tl:longitude>
    <tl:altitude>30.0</tl:altitude>
    <tl:accuracy>55</tl:accuracy>
    <tl:timestamp>2012-04-17T09:21:32.893+02:00</tl:timestamp>
   </tl:currentLocation>
   <tl:errorInformation>
    <common:messageId>QOP_NOT_ATTAINABLE</common:messageId>
    <common:text>The requested QoP cannot be provided.</common:text>
   </tl:errorInformation>
  </tl:terminalLocation>
 </tl:terminalLocationList>

Location Subscriptions

This type of query is used to retrieve either periodic location reports or area entry/leaving/inside/outside location events from a target terminal. The message flow is illustrated below:

Image:Location Subscription.gif

The Location GE receives in this case an HTTP POST method including many parameters that are used for the authentication of the third-party application and quality of position parameters that define the type of location/events requested.The full list of supported parameters isprovided in API Specifications(see references). An example of a request is provided below:

 POST /location/v1/subscriptions/periodic HTTP/1.1
 Accept: application/xml
 Host: example.com
 Content-Length: nnnn

 <?xml version="1.0" encoding="UTF-8"?>
 <tl:periodicNotificationSubscription xmlns:common="urn:oma:xml:rest:netapi:common:1"
xmlns:tl="urn:oma:xml:rest:netapi:terminallocation:1">
 <tl:clientCorrelator>0003</tl:clientCorrelator>
 <tl:callbackReference>
   <tl:notifyURL>http://application.example.com/notifications/LocationNotification</tl:notifyURL>
   <tl:callbackData>4444</tl:callbackData>
 </tl:callbackReference>
 <tl:address>tel:+19585550100</tl:address>
 <tl:requestedAccuracy>10</tl:requestedAccuracy>
 <tl:frequency>10</tl:frequency>
 <tl:duration>100</tl:duration>
 </tl:periodicNotificationSubscription>
 

Once authenticated, the location request triggers a SUPL transaction towards the target handset to program it with requested information. When acknowledged by the handset, the following response is returned:

 HTTP/1.1 201 Created
 Content-Type: application/xml
 Location: http://example.com/location/v1/subscriptions/periodic/sub003
 Content-Length: nnnn
 Date: Thu, 02 Jun 2011 02:51:59 GMT

 <?xml version="1.0" encoding="UTF-8"?>
 <tl:periodicNotificationSubscription xmlns:common="urn:oma:xml:rest:netapi:common:1"  xmlns:tl="urn:oma:xml:rest:netapi:terminallocation:1">
 <tl:clientCorrelator>0003</tl:clientCorrelator>
 <tl:resourceURL>http://example.com/location/v1/subscriptions/area/circle/sub003</tl:resourceURL>
 <tl:callbackReference>
 <tl:notifyURL>http://application.example.com/notifications/LocationNotification</tl:notifyURL>
 <tl:callbackData>4444</tl:callbackData>
 </tl:callbackReference>
 <tl:address>tel:+19585550100</tl:address>
 <tl:requestedAccuracy>10</tl:requestedAccuracy>
 <tl:frequency>10</tl:frequency>
 <tl:duration>100</tl:duration>
 </tl:periodicNotificationSubscription>
 

Each location / event report sent by the SET to the Location GE is then forwarded to the client application using a POST method containing the following data:

 POST /notifications/LocationNotification HTTP/1.1
 Content-Type: application/xml
 Accept: application/xml
 Host: application.example.com
 Content-Length: nnnn

 <?xml version="1.0" encoding="UTF-8"?>
 <tl:subscriptionNotification xmlns:common="urn:oma:xml:rest:netapi:common:1" xmlns:tl="urn:oma:xml:rest:netapi:terminallocation:1">
 <tl:callbackData>4444</tl:callbackData>
 <tl:terminalLocation>
 <tl:address>tel:+19585550100</tl:address>
 <tl:locationRetrievalStatus>Retrieved</tl:locationRetrievalStatus>
 <tl:currentLocation>
 <tl:latitude>-80.86302</tl:latitude>
 <tl:longitude>41.277306</tl:longitude>
 <tl:altitude>1001.0</tl:altitude>
 <tl:accuracy>100</tl:accuracy>
 <tl:timestamp>2011-06-02T00:27:23.000Z</tl:timestamp>
 </tl:currentLocation>
 </tl:terminalLocation>
 <tl:link rel="CircleNotificationSubscription"
href="http:/location/v1/subscriptions/periodic/sub0003"/>
 </tl:subscriptionNotification>
 

Fleet Simulation Tool

Mobile Simulation

Here is an example of a path addition:

Request :

 POST /testtool/simulation/mobilepaths HTTP/1.1
 Accept: application/xml
 Host: example.com
 Content-Length: nnnn

<?xml version="1.0" encoding="UTF-8"?>
<simulationFragment>
  <name>Test Route</name>
  <pathRoutes>
     <pathRoute>
      <context>
          <msisdn>33611223344</msisdn>
          <velocity>1.0</velocity>
          <autoMove>true</autoMove>
          <autoLoop>true</autoLoop>
          <logPath>false</logPath>
      </context>
      <positions>
          <position>
            <name>Position 0</name>
            <latitude>43.545571</latitude>
            <longitude>1.387802</longitude>
            <altitude>31.0</altitude>
          </position>
          <position>
            <name>Position 1</name>
            <latitude>43.5453</latitude>
            <longitude>1.3883</longitude>
            <altitude>31.0</altitude>
          </position>
          <position>
            <name>Position 2</name>
            <latitude>43.545107</latitude>
            <longitude>1.388511</longitude>
            <altitude>31.0</altitude>
          </position>
          <position>
            <name>Position 3</name>
            <latitude>43.544992</latitude>
            <longitude>1.388417</longitude>
            <altitude>31.0</altitude>
          </position>
          <position>
            <name>Position 4</name>
            <latitude>43.545083</latitude>
            <longitude>1.387808</longitude>
            <altitude>31.0</altitude>
          </position>
          <position>
            <name>Position 5</name>
            <latitude>43.545240</latitude>
            <longitude>1.387856</longitude>
            <altitude>31.0</altitude>
          </position>
      </positions>
     </pathRoute>
  </pathRoutes>
</simulationFragment>

Response :

 HTTP/1.1 201 Created
 Content-Length: nnnn
 Date: Thu, 02 Jun 2011 02:51:59 GMT

Scenario Management

Here is an example of a scenario selection and start-up: Request :

 PUT http://127.0.0.1:8111/testtool/scenario/control?select=LocationGE-TriggerSubscription  HTTP/1.1
 Host: example.com

Response :

 HTTP/1.1 200 OK
 Content-Length: nnnn
 Date: Thu, 02 Jun 2011 02:51:59 GMT

Request :

 PUT http://127.0.0.1:8111/testtool/scenario/control?cmd=start  HTTP/1.1
 Host: example.com

Response :

 HTTP/1.1 200 OK
 Content-Length: nnnn
 Date: Thu, 02 Jun 2011 02:51:59 GMT

SUPL Positioning

A-GNSS location technology

In all SUPL transactions presented before, the Location GE and the SET may exchange GNSS (Global Navigation Satellite System) assistance data in order to improve mainly time to first fix and handset sensitivity. SUPL is used as transport layer to carry the following assistance data encoded in RRLP (Radio Resource Location Protocol) format:

  • Almanac
  • UTC model
  • Ionospheric model
  • DGPS corrections
  • Reference location
  • Reference time
  • Acquisition assistance
  • Real-time integrity
  • Navigation model

Based on this assistance data, the handset only needs to acquire satellites and use the provided information to either compute its position (ms-based mode) or provide its pseudo-range measurements to the Location GE to get its position (ms-assisted mode).

C-ID location technology

The first SUPL message sent by the handset contains location identifier(s). Those identifiers can be of type 'GSM', 'WCDMA' (3G) or 'WLAN' (Wi-Fi). Based on the internal database, the Location Platform is able to convert those identifiers into a position and, in case of multiple location identifiers, perform triangulation of those access points.

Location Technology selection

Today, C-ID (including Wi-Fi) is always used based on the location identifiers returned by the SET, as part of the SUPL exchange. A-GPS is only used if the third-party application is authorized to perform precise positioning. An evolution of the location technology selection is planned in future FI-WARE releases, as described below.

Depending on the content of the location request and the end-user environment recognized by its cell, the Location GE will decide what Location Technology to use. The following parameters will contribute to this decision:

  • End-user environment: indoor, outdoor
  • QoP parameters: delay, accuracy
  • Client type: standard or emergency

NGSI Integration with Context Broker GE

In order to provide better decoupling between Location GE and location aware target applications, an optional NGSI Integration feature is available. In that case, applications receives positionning information through NGSI Pub/Sub API messages (FI-WARE NGSI API).

The Location GE NGSI integration schema can be summarized in the following sequence diagram covering :

  • Initial entity registration
  • Location query NGSI scenario
  • Trigger Subscription NGSI scenario

The rationale is to insure complete compatibility with the OMA Terminal Location RESTFull API by adding limited extensions and profile format for callback data. In these scenarios, notification (end-point) URL refers always to Context Broker URL.


Image:LOCS-NGSI.gif

Basic Design Principles

The Location GE is based on existing OMA standards (refer to [7]):

  • MLP: DTDs are available from the OMA website.
  • NetAPI Terminal location: refer to Location GE RESTful API
  • SUPL: ASN.1 data format is provided as part of the SUPL specification.

The 3GPP RRLP standard is also followed for GNSS assistance data exchange.

References

MLP

Mobile Location Protocol (MLP), Open Mobile Alliance, specification OMA-TS-MLP-V3_2-20110719-A

SUPL

Secure User Plane Location Protocol (SUPL), Open Mobile Alliance, specification OMA-TS-ULP-V2_0-20111222-D

RRLP

Radio Resource LCS Protocol (RRLP), 3GPP, specification 3GPP TS 44.031 V9.2.0 (2010-03)


Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.

Open API Specifications


Re-utilised Technologies/Specifications

The following technologies/specifications are incorporated in this GE :

  • Mobile Location Protocol (MLP), Open Mobile Alliance, as specified in OMA-TS-MLP-V3_2-20110719-A,
  • Secure User Plane Location Protocol (SUPL), Open Mobile Alliance, as specified in OMA-TS-ULP-V2_0-20111222-D
  • Radio Resource LCS Protocol (RRLP), 3GPP, as specified in 3GPP TS 44.031 V9.2.0 (2010-03)
  • Terminal Location API, Open Mobile Alliance, as specified in REST_NetAPI_TerminalLocation_V1_0-20120207-C

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FIWARE has associated a data type and avalue. FIWARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FIWARE are referred as basic data values. As an example, basic data values like ‘2’, ‘7’ or ‘365’ belong to the integer basic data type.
  • A data element refers to data whose value is defined as consisting of a sequence of one or more <name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.
  • Context in FIWARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FIWARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters” and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.
  • An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".
  • A data event refers to an event leading to creation of a data element.
  • A context event refers to an event leading to creation of a context element.
  • An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.
Personal tools
Create a book