[pcap-ng-format] Proposing new block type for PCAP-NG (UNCLASSIFIED)

[Guy Harris]

On Apr 1, 2015, at 12:49 AM, Anders Broman <anders.broman at ericsson.com> wrote:

> There is Universal Geographical Area Description (GAD) (3GPP TS 23.032 version 12.0.0 Release 12) http://www.etsi.org/deliver/etsi_ts/123000_123099/123032/12.00.00_60/ts_123032v120000p.pdf

So the polygon and ellipsoid arc appear to be intended to describe areas; I guess they could be used if you want to give a location that's "inside this area" rather than "at this point".

Ellipsoid point is similar to Latitude-Longitude-Altitude but without the altitude, and ellipsoid point with altitude is, obviously, similar to Latitude-Longitude-Altitude.  The differences are:

	the Universal Geographical Area Description has a 24-bit sign+magnitude latitude, where (latitude/90) is expressed as a 24-bit binary fixed-point fraction of 1, a 24-bit 2's complement longitude, where (longitude/360) is expressed as a 24-bit binary fixed-point fraction of 1, and a 16-bit sign+magnitude altitude, with positive being above the WGS84 ellipsoid and negative being below it, in units of meters;

	the proposed Latitude-Longitude-Altitude has a 32-bit 2's complement signed latitude in units of millionths of a degree, a 32-bit 2's complement signed longitude in units of millionths of a degree, and a 32-bit 2's complement signed altitude, with positive being above mean sea level and negative being below it, in units of meters.

In addition, the Universal Geographical Area Description also allows an uncertainty ellipsoid to be provided along with the location, and supports specifying velocity.  (Presumably the size of the uncertainty ellipsoid of the position imposes a minimum size on the size of the uncertainty ellipsoid of the velocity, unless the mass of the object is sufficiently uncertain. :-))

So the big differences - as opposed to encoding differences - are:

	resolution of latitude and longitude;

	availability of 2D-only position information;

	availability of an uncertainty ellipsoid;

	availability of velocity information;

	availability of polygon/ellipsoid arc information.

> GSM MAP 3GPP TS 29.002
> GeodeticInformation ::= OCTET STRING (SIZE (10))
> -- Refers to Calling Geodetic Location defined in Q.763 (1999).

So Q.763 (ISUP):

	http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=4788

supports:

	ellipsoid point and ellipsoid point with uncertainty (so latitude+longitude with no altitude), encoded similarly to the Universal Geographical Area Description;

	point with altitude, and point with altitude with uncertainty, with altitude relative to some (unspecified?) ellipsoid (WGS84 ellipsoid? mean sea level ellipsoid?);

	ellipse on the ellipsoid, with the center of the ellipse, major axis, minor axis, and orientation (i.e., specifying an area);

	circular sector on the ellipsoid, with the center of the circle, radius of the circle, orientation of the sector, and included angle of the sector (also specifying an area);

	polygon;

which is a similar set to the Universal Geographical Area Description.

> Positioning Calculation Application Part (PCAP)

Well, citing *that* certainly should make things confusing. :-)

"PCAP in PCAP-NG?  What?"

> signaling
> (3GPP TS 25.453 version 12.2.0 Release 12) http://www.etsi.org/deliver/etsi_ts/125400_125499/125453/12.02.00_60/ts_125453v120200p.pdf

That seems to have similar location information to the above (to the extent that it even says, for the "Geographical Area" IE in section 9.2.2.6, "The reference system is the same as the one used in TS 23.032 [11]."

It describes what appears to be a protocol for requesting location information, so it has, for example, the ability to report failures to get location information.  It also appears to allow information about the satellites used to determine the position.

We probably don't need a lot of the stuff there, as we're just recording positions; we're not a protocol for *requesting* positions.

So:

The encoding differences between Q.763 and the various 3GPP standards, and the proposal, probably don't matter.  The mobile phone standards were originally designed for low-data-rate networks, so they tend to try to economize on bits; we don't need to worry about that for positions in capture files, so we can probably go with encodings such as the ones in the proposal.

The additional location types, such as "latitude+longitude but not altitude", the ones that describe areas, and the ones that include uncertainty information, might be useful.  Pcap-ng is nicely extensible, so we don't have to define all of them immediately - we can add additional ones as necessary.

So I wouldn't change any of the encodings in the proposal, but we might want to consider adding some additional location types, again, not necessarily using the same encodings as the 3GPP standards.

(Note that the proposal also includes orientation, in the form of roll, pitch, and yaw angles; unless I missed something, those aren't in any of the 3GPP specifications.)