Re: [netext] Question about extending the ANI option

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

Hi Raj

1. Why is the existing ANI option not sufficient for encoding WLAN specific information?
2. Is the primary goal to provide information regarding location? And as a means for indoor location tracking?




1)      RFC 6757 defines three ANI Types: Network Identifier, Geo-Location, Operator Identifier.  For WLAN deployments, there is a need in many cases (e.g., regulatory,  location based services, location based policy, etc) to identify the AP the user is attached to.  RFC 6757 provides one way to do it via Geo-Location. However, many indoor APs are unlikely to have GPS to provide Geo-location. However, these indoor APs are often provisioned with a Civic location today. RFC 6757 does not provide a way to encapsulate Civic Location. So we are proposing adding a new ANI Type: Civic Location.  We are also defining another ANI Type: Group Identifier. In many existing deployments APs are grouped together with a group-id. The group identifier refers to a coarse location such as a specific coffee-store, book-store, etc.  This form of ANI information is also useful in facilitating many location based applications.

2)      The primary goal is indeed for the MAG to provide location information about the Access Point that the user is attached to. RFC 6757 provided a way to provide GPS. But GPS does not work well in indoor deployments and sometimes is considered expensive for indoor APs. As a result, we are looking for alternatives. The two alternatives proposed: Civic Location, and Group-Identifier.

The I-D does not really explain the key problem to be solved other than saying that 3GPP has a requirement in WLAN deployments. It would be good if you can explain the motivation to the WG so that the WG can decide on adopting and progressing this I-D.


Hopefully the above answers provide some further explanation.  I agree saying that 3GPP has a requirement in not adequate by itself. We cited that as a reference or evidence that there is a real problem in the larger community that needs addressing.

When, I presented this draft in Vancouver last year, there was a fair bit of interest on the floor. If I recall correctly, Rajeev asked for a show of hands and a number of hands went up in support. I am hoping to get the same folks voice their support on the mailing list ☺

Regards

Rajesh

From: Basavaraj Patil [mailto:[e-mail]]
Sent: Wednesday, May 07, 2014 7:08 AM
To: [e-mail]
Cc: [e-mail]
Subject: Question about extending the ANI option


Hello authors,

Couple of questions regarding the problem being that this I-D aims to solve:

1. Why is the existing ANI option not sufficient for encoding WLAN specific information?
2. Is the primary goal to provide information regarding location? And as a means for indoor location tracking?

The I-D does not really explain the key problem to be solved other than saying that 3GPP has a requirement in WLAN deployments. It would be good if you can explain the motivation to the WG so that the WG can decide on adopting and progressing this I-D.

-Raj

--
Basavaraj Patil