Re: [netext] Question about extending the ANI option

[Basavaraj Patil <[e-mail]>]

Hi Rajesh,

Thanks for the response.

So the objective is for the LMA to get location information about the MN
w.r.t the WiFi AP that it is attached to.
In a 3GPP context, the LMA is part of the PGW. Does the PGW not have access
to this information?

The PGW has location information w.r.t the cellular location. And I agree
that indoor location w.r.t GPS is an issue.
Question is whether the only source of information for the PGW/LMA about
the AP that the MN is attached to via the PMIP6 PBU?

Rgds,
-Raj


On Wed, May 7, 2014 at 9:42 AM, Rajesh Pazhyannur (rpazhyan) <
[e-mail]> wrote:

>  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 J
>
>
>
> 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
>



-- 
Basavaraj Patil