Subject: [netext] Question about extending the ANI option

From: Basavaraj Patil <[email-masked]>
Date: Wed, 7 May 2014 09:08:22 -0500

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

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Wed, 7 May 2014 14:42:21 +0000

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:[email-masked]]
Sent: Wednesday, May 07, 2014 7:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: Question about extending the ANI option

Hello authors,

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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 7 May 2014 10:47:05 -0500

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) <
[email-masked]> wrote:

> 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.
>
>
>
> 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:[email-masked]]
> *Sent:* Wednesday, May 07, 2014 7:08 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Question about extending the ANI option
>
>
>
>
>
> Hello authors,
>
>
>

-- 
Basavaraj Patil

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Wed, 7 May 2014 16:02:54 +0000

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?

Ø  The technically right answer is that PMIPv6  is *not* the only source of information. As I indicated in earlier email, today’s implementation use Radius 5580 and/or DHCP Option 82 to send location information.

Ø  However, RFC 6757 provided a way to signal geo-location “in-band”. This approach is preferable to some operators. We feel that such deployments will benefit from further enhancement in the form of Civic-location and Group-Id.
From: Basavaraj Patil [mailto:[email-masked]]
Sent: Wednesday, May 07, 2014 8:47 AM
To: Rajesh Pazhyannur (rpazhyan)
Cc: [email-masked]; [email-masked]
Subject: Re: Question about extending the ANI option

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Raj

Regards

Rajesh

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

Hello authors,

-Raj

--
Basavaraj Patil

--
Basavaraj Patil