Skip to main content

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint identification

  • From: Werner Keil < >
  • To:
  • Subject: [jsr360-experts] Re: [jsr360-observers] Re: Accesspoint identification
  • Date: Wed, 27 Nov 2013 13:00:07 +0100

Thomas/all,

Thanks for raising this. During last week's Eclipse DemoCamps with an M2M
focus both by my own presentations and Telekom's "Eclipse SmartHome" at FZI
Karlsruhe the speaker (OpenHAB lead, you should know him from Duke Awards)
had an interesting "Aha" experience with one of his fancy Wireless
no-battery light switches.

Being an "IoT Think Tank" (@Thomas there is one in Berlin, too, but I am
not sure if it was the host of prior DemoCamps or not) FZI Karlsruhe had
the same light switches and during his talk the speaker ended up switching
some light in the closet or attic of FZI on and off instead of his own lamp
[?] After a full restart of the app and OSGi container it eventually sorted
itself out, but this was a striking example of not so well established
Device Identity. If you have a device type and name or some ID, the
algorithms to generate new IDs would have to be very sophisticated to avoid
that. I don't recall the exact matter of his identity criteria, either Mac
adress, IP or similar, but it failed to allow correct communication between
the two. Kind of like a cloned door key opener for cars used by tech-savvy
car thieves these days.[?]

Kind Regards,
Werner

On Wed, Nov 27, 2013 at 11:52 AM, Lampart Thomas 
<
> wrote:

>  Hi Roger,
>
>
>
> Thanks for clarification.
>
> Ok, let me redefine my statement a little bit: I assumed that Accesspoint
> Type and Name together are unambiguous.
>
>
>
> But you are right, in case of wifi there could be several networks with
> the same name in the air and you could do nothing about it. So they would
> be difficult to distinguish. But that’s probably a problem every platform
> that uses wifi faces ?!
>
>
>
> And for 3GPP you solve such a problem by adding the operator. ok
>
>
>
> So the Accesspoint getName() method does return the SSID for wifi and the
> APN for 3G ? It probably should ?
>
>
>
> If this is the case I get the idea behind.
>
>
>
> Regarding the use case of using different PDP contexts with same APN for
> the sake of having different IP addresses, I can confirm that we have a
> customer which does that. But unfortunately there is no really good reason
> for doing so ;-) So I guess it is not high priority to support that.
>
>
>
> *So it’s basically fine for me, I would like to suggest only two minor
> fixes:*
>
> *-mention in the spec that an empty APN is a valid APN (e.g.
> ConnectionOption<String> apn2 = new ConnectionOption<>("apn", "");), and it
> means network default APN*
>
> *-add “dnsserver” to the list of optional parameters for creating 3GPP or
> dialup/CSD Accesspoints (this is not directly related to our discussion
> here but its useful ;-)*
>
>
>
> Best regards
>
>   Thomas
>
>
>
>
>
>
>
> *From:* roger riggs 
> [mailto: ]
> *Sent:* Dienstag, 26. November 2013 18:40
> *To:* 
> 
> *Subject:* [jsr360-observers] [jsr360-experts] Re: Accesspoint
> identification
>
>
>
> Hi Thomas,
>
> AccessPoints are not assumed to have a unique name, for example a WiFi
> AccessPoint might be "T-mobile" and a 3GPP AccessPoint might have the same
> name.
> For WiFi even there can be two "foovar" networks visible at the same time.
> In this case, I don't think there is any way to distinguish between them.
>
> Michael pointed out the ETSI specifications[1] Chapter 9, include fully
> qualified names, though the full name elements can be optional.
>
> The apnoperator property does seem redundant if the APNs are fully
> qualified.
>
> In the case where the application wants to fully control exactly which SIM
> card is used to register with which network and which AccessPoint is
> connected will need to use the API to explicitly call the APIs to set it up
> that way.
>
> You mention " just for the sake of communicating from different IP
> addresses".
>
> Can you expand on the use case?
>
> The current AccessPoint design would not have multiple AccessPoints for a
> single APN.
> An AccessPoint would exist for each APN known to the implementation.
> The AccessPoint.of() method would return the AccessPoint corresponding to
> the APN when requested; not create a new AccessPoint.
> The TCP/IP addresses are allocated by the device implementation perhaps in
> cooperation with the network and DHCP or equivalent.
>
> A distinct AccessPoint and APN could be created only with a new
> (previously unknown) name.
>
> What needs to be fixed here?
>
> Thanks, Roger
>
>
>
> [1]
> http://www.etsi.org/deliver/etsi_ts/123000_123099/123003/11.06.00_60/ts_123003v110600p.pdf
>
> On 11/26/2013 11:43 AM, Lampart Thomas wrote:
>
> Hi Roger,
>
>
>
> Thanks for your feedback.
>
> It is correct that APNs are operator specific.
>
> Unfortunately putting the apnoperator name here does not help to clearly
> identify an AccessPoint. You might want to have different AccessPoints with
> same APN and same apnoperator, e.g. just for the sake of communicating from
> different IP addresses.
>
> I actually always assumed that the AccessPoint name (getName()) is the
> only parameter which allows to clearly identify an Accesspoint. What do you
> think about that ?
>
> So instead making the name a required parameter when creating an
> Accesspoint would make more sense for me.
>
>
>
> Best regards
>
>   Thomas
>
>
>
>
>
>
>
> *From:* roger riggs 
> [mailto: < >]
>
> *Sent:* Dienstag, 26. November 2013 17:29
> *To:* 
> 
> *Subject:* [jsr360-experts] Re: [jsr360-observers] Accesspoint
> identification
>
>
>
> Hi Thomas,
>
> It was observed that APNs are operator specific and in many cases
> provisioned by the operators and may have names that if left unqualified
> would be ambiguous.  Since the of() method needs to be able to select a
> unique AccessPoint it seemed that the name of the operator is required.
>
> I'd be happy to be corrected to simplify the interface.
>
> Thanks, Roger
>
> On 11/26/2013 11:09 AM, Lampart Thomas wrote:
>
>  Dear specleads, experts,
>
>
>
> today I stumbled over something in the AccessPoint class spec which
> confused me a bit.
>
> To find or create a 3GPP AccessPoint using AccessPoint.of the type is
> "3GPP" and the ConnectionOptions are:
>
>    - apn - required, a ConnectionOption<String>; apns many apns are
>    predefined and provisioned by the network operator and additional APNs 
> can
>    be created as needed
>    - apnoperator - required, the name of the operator providing the APN
>
> What would this “apnoperator” as required parameter be ? What relevance
> would it have ?
>
> To me this seems to be just some random text which does maybe not make
> sense when you CREATE an AccessPoint.
>
>
>
> Wouldn’t it make more sense here to have a “name” as required parameter
> here. A name which can be used to clearly identify the Accesspoint. THE
> name which can be queried with getName() method ?
>
>
>
> Best regards
>
>   Thomas
>
>
>
>
>  ------------------------------
>
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus
>
>
>
>
>  ------------------------------
>
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus
>
>
>
> ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus
>

Attachment: 338.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



[jsr360-experts] JSR 360 EG call notes (revised) - Tuesday Nov 12th

(continued)

[jsr360-experts] JSR 360 EG call notes (revised) - Tuesday Nov 12th

Michael Lagally 11/12/2013

[jsr360-experts] Accesspoint selection for Ping and DNS

Lampart Thomas 11/19/2013

[jsr360-experts] Re: [jsr360-observers] Accesspoint selection for Ping and DNS

Michael Lagally 11/19/2013

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint selection for Ping and DNS

Lampart Thomas 11/19/2013

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint selection for Ping and DNS

Michael Lagally 11/25/2013

[jsr360-experts] [jsr360-observers] Accesspoint identification

Lampart Thomas 11/26/2013

[jsr360-experts] Re: [jsr360-observers] Accesspoint identification

roger riggs 11/26/2013

[jsr360-experts] Re: [jsr360-observers] Accesspoint identification

Lampart Thomas 11/26/2013

[jsr360-experts] Re: [jsr360-observers] Accesspoint identification

roger riggs 11/26/2013

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint identification

Lampart Thomas 11/27/2013

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint identification

Werner Keil 11/27/2013

[jsr360-experts] Re: [jsr360-observers] Re: Accesspoint identification

roger riggs 11/27/2013

[jsr360-experts] Re: [jsr360-observers] Re: Re: Accesspoint identification

Lampart Thomas 11/27/2013

[jsr360-experts] Re: [jsr360-observers] Accesspoint selection for Ping and DNS

Michael Lagally 11/19/2013
 
 
Close
loading
Please Confirm
Close