Re: [802.21] SPAM-LOW: Re: [802.21] SPAM-LOW: Re: [802.21] SPAM-LOW: Re: [802.21] Issue #6 Which operator should we expose in IEs? (doc: 21-06-0667-00-0000_Comment Assignments)
On Thu, Jun 15, 2006 at 11:59:43AM -0700, Gupta, Vivek G wrote:
> > This is where semantic query provided by XML/RDF can be really useful.
> > MN just needs to ask "Is operator A a roaming partner of operator B?"
> > where A is access network operator advertised by the access network
> > and B is the operator to which the MN is subscribed. And the expected
> > response for the query is just "Yes" or "No".
>
> This can be enabled in other forms (using TLV as well) and is not really
> restricted to XML only. Given that some of the IEs are gonna be quite
> large in size, this may be the preferred way of operating and we need to
> specify such queries that give better performance.
This is true. On the other hand, it might be hard to come up with a
satisfactory pre-defined set of query patterns for TLV. There is a
comment on this in D01 commentary and this issue has already been
identified in Annex A of 21-05-0347-00-0000-XML_IS_Introduction.doc.
This is one of the reasons for allowing both TLV and XML.
Yoshihiro Ohba
> Clients could still pull down all the information available at the
> information server at their own discretion (for whatever reason) and be
> aware of the cost implications. But having a more optimized query
> mechanism (w.r.t payload over the air) should help in achieving better
> performance.
>
> Best Regards
> -Vivek
>
> > -----Original Message-----
> > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
> > Yoshihiro Ohba
> > Sent: Wednesday, June 07, 2006 6:33 PM
> > To: Phillip Barber
> > Cc: STDS-802-21@listserv.ieee.org
> > Subject: Re: [802.21] SPAM-LOW: Re: [802.21] SPAM-LOW: Re: [802.21]
> SPAM-
> > LOW: Re: [802.21] Issue #6 Which operator should we expose in IEs?
> (doc:
> > 21-06-0667-00-0000_Comment Assignments)
> >
> > On Wed, Jun 07, 2006 at 05:51:15PM -0500, Phillip Barber wrote:
> > > I agree with your observations.
> > >
> > > I see 802.21's job as a facilitator to help namespace/numberspace
> > > management reach a common understanding so interoperable, common
> > behavior
> > > can result. But 802.21 does not have adequate mandate or authority
> to
> > > enforce such action on other SDOs.
> > >
> > > But I have to say, 253 byte string fields are wholly unacceptable
> for
> > air
> > > interface broadcast events in any timely manner that would be
> useful.
> > Bear
> > > in mind that broadcast events are invariably transmitted at the
> worst
> > > possible burst profile. It is a burden if you have to transmit a
> single
> > 253
> > > byte Operator ID code every minute or so. It is completely untenable
> if
> > you
> > > have to transmit a list of twenty or a hundred of these every
> second,
> > which
> > > can happen if the Access Network supports multiple CSNs, especially
> with
> > > the support of virtual CSNs. And lets not forget over-the-air
> > transmission
> > > of the CSN IDs for roaming partners. So the size of the Operator ID
> that
> > is
> > > viable is tied to the quantity of Operator IDs to be transmitted
> > > over-the-air and the frequency of broadcast of these values. Even as
> > > unicast transmissions to individual MS, made with more robust burst
> > > profiles, this could be pretty large blobs of data.
> >
> > This is where semantic query provided by XML/RDF can be really useful.
> > MN just needs to ask "Is operator A a roaming partner of operator B?"
> > where A is access network operator advertised by the access network
> > and B is the operator to which the MN is subscribed. And the expected
> > response for the query is just "Yes" or "No".
> >
> > Yoshihiro Ohba
> >
> > >
> > > Thanks,
> > > Phillip Barber
> > > Chief Scientist
> > > Broadband Wireless Solutions
> > > Huawei Technologies Co., LTD.
> > >
> > > ----- Original Message -----
> > > From: "Qiaobing Xie" <Qiaobing.Xie@motorola.com>
> > > To: "Phillip Barber" <pbarber@BROADBANDMOBILETECH.COM>
> > > Cc: <STDS-802-21@LISTSERV.IEEE.ORG>
> > > Sent: Wednesday, June 07, 2006 5:40 PM
> > > Subject: SPAM-LOW: Re: [802.21] SPAM-LOW: Re: [802.21] SPAM-LOW: Re:
> > > [802.21] Issue #6 Which operator should we expose in IEs? (doc:
> > > 21-06-0667-00-0000_Comment Assignments)
> > >
> > >
> > > Phillip Barber wrote:
> > >
> > > >I disagree.
> > > >
> > > >The whole point of having a standardized media independent way of
> > > >conducting handover was to make it so that each of the technologies
> > could
> > > >have a single model to write to, 802.21, instead of creating
> different
> > > >proprietary models of there own, each for different technologies.
> What
> > you
> > > >propose then would be to have 3GPP2 write one method of identifying
> > > >networks and negotiating handover among various technologies, 3GPP
> > > >creating a different method, 802.16 creating another, 802.11
> creating
> > > >another, etc.... And it does not sound to me like any of them would
> be
> > > >interoperable.
> > >
> > > The focus here is just the Operator Name field, what should be put
> there
> > > and what the value should mean. I don't think any one is talking
> about
> > > abandoning 802.21. From the previous discussion on this thread, the
> > > syntax and semantics of operator name clearly have a strong
> connection
> > > to the business model and agreement (who own which part of what). I
> just
> > > don't see how 802.21 by itself can impose anything there.
> > >
> > > >It sounds to me like you are endorsing having each industry segment
> > create
> > > >its own methodology which, once again, create multiple
> non-standardized
> > > >methods for conducting handover. Please correct me if I
> misunderstand.
> > >
> > > We create the technology that allows everyone to associate with
> everyone
> > > else. But whether that will happen is beyond 802.21. In this
> particular
> > > case, a container will work - if the entire community can agree to
> have
> > > a single association, then they simply define and manage a universal
> > > namespace and put the name in the container. If not, they define
> > > separate namespace and put the name in the container. Either way,
> the
> > > 802.21 container will work just fine.
> > >
> > > >
> > > >If all you wanted was some payload 'hooks' then none of 802.21 is
> > really
> > > >necessary. You could have just gone to each of the technology
> specific
> > > >standards bodies and asked for the hooks. 802.21 only exists to
> create
> > a
> > > >common, standardized method to use those hooks. 802.21 is glue
> > language;
> > > >the common language that each of the other bodies writes to. So
> 802.21
> > has
> > > >to create the common interface for that action. That means mapping
> and
> > > >presenting information elements like network identifiers in some
> common
> > > >manner so that other technologies, other implementations will have
> a
> > > >common understanding and can create MS and network behavioral
> models
> > that
> > > >can achieve similar and consistent handover results.
> > >
> > > I did not intend to generalize the discussion. Let's only talk about
> the
> > > operator name here. When an "operator name" IE is sent from A to B,
> > > 802.21 takes the value from A and pass to B and makes sure that B
> will
> > > understand this blob of data is an "operator name" IE, but 802.21
> will
> > > not say anything about whether the value is right/wrong, good/bad,
> > > legal/illegal, allowed/disallowed, etc. This because only the name
> > > authority can judge the value of the name field. I don't see 802.21
> can
> > > or should play that role.
> > >
> > > regards,
> > > -Qiaobing
> > >
> > > >
> > > >Just my opinion.
> > > >
> > > >Thanks,
> > > >Phillip Barber
> > > >Chief Scientist
> > > >Broadband Wireless Solutions
> > > >Huawei Technologies Co., LTD.
> > > >
> > > >----- Original Message ----- From: "Qiaobing Xie"
> > > ><Qiaobing.Xie@motorola.com>
> > > >To: "Phillip Barber" <pbarber@BROADBANDMOBILETECH.COM>
> > > >Cc: <STDS-802-21@listserv.ieee.org>
> > > >Sent: Wednesday, June 07, 2006 1:27 PM
> > > >Subject: SPAM-LOW: Re: [802.21] SPAM-LOW: Re: [802.21] Issue #6
> Which
> > > >operator should we expose in IEs? (doc: 21-06-0667-00-0000_Comment
> > > >Assignments)
> > > >
> > > >
> > > >Being a "Placeholder" means some secondary stds body (for example
> an
> > > >cellular and non-cellular network owner/operator association that
> wants
> > > >to build a cross-tech mega roaming/handover service network based
> on
> > > >802.21 technology) will have to step in after the completion of
> 802.21
> > > >spec and define and manage their own operator/owner namespace.
> > > >Interoperability would thus be guaranteed within that association.
> > > >
> > > >I don't see how 802.21 alone can accomplish network
> interoperability
> > > >without the involvement of the actual owners/operators anyway.
> > > >
> > > >regards,
> > > >-Qiaobing
> > > >
> > > >Phillip Barber wrote:
> > > >
> > > >>You could do it, but I would not expect interoperability. That is
> to
> > say,
> > > >>there would be no consistent presentation of information, so no
> Mobile
> > > >>Station behavior could be standardized because information is not
> > > >>reliably/consistently provided. If you don't care about
> > interoperability
> > > >>you could simply create a generic payload delivery method and let
> > vendors
> > > >>stuff whatever proprietary info into those payloads that they care
> to.
> > > >>
> > > >>Thanks,
> > > >>Phillip Barber
> > > >>Chief Scientist
> > > >>Broadband Wireless Solutions
> > > >>Huawei Technologies Co., LTD.
> > > >>
> > > >>----- Original Message ----- From: "Qiaobing Xie"
> > > >><Qiaobing.Xie@MOTOROLA.COM>
> > > >>To: "Subir Das" <subir@RESEARCH.TELCORDIA.COM>
> > > >>Cc: <STDS-802-21@listserv.ieee.org>
> > > >>Sent: Wednesday, June 07, 2006 11:27 AM
> > > >>Subject: SPAM-LOW: Re: [802.21] Issue #6 Which operator should we
> > expose
> > > >>in IEs? (doc: 21-06-0667-00-0000_Comment Assignments)
> > > >>
> > > >>
> > > >>Why not simply define it as a 802.21 placeholder/container
> > > >>"Owner/Operator Info" IE containing an unrestricted character
> string
> > and
> > > >>let the actual operators/owners/partners associations (like the
> > current
> > > >>GSMA) to decide whatever most suitable for their then business
> model
> > to
> > > >>put in there.
> > > >>
> > > >>regards,
> > > >>-Qiaobing
> > > >>
> > > >>Subir Das wrote:
> > > >>
> > > >>>Phillip Barber wrote:
> > > >>>
> > > >>>>I would tend to agree. The mere identification that there is a
> > roaming
> > > >>>>agreement--that is to say the identification of a Visited CSN
> (with
> > > >>>>appropriate AAA) with a roaming agreement to a Mobile
> Subscriber's
> > Home
> > > >>>>CSN--is available may very well be adequate.
> > > >>>
> > > >>>
> > > >>>
> > > >>>I would also agree. But why does MS need to know the Visited AAA?
> > Corner
> > > >>>case: where L1/L2 and L3/L4 operators are different in a visited
> > network
> > > >>>(assuming Home Network has roaming agreement with both of them),
> > which
> > > >>>operator's information should be exposed? Anyone or both of them?
> > > >>>
> > > >>>>As for identification of Visited CSNs that have a roaming
> agreement
> > > >>>>with a given Home CSN, the list may be presented over-the-air or
> in
> > a
> > > >>>>configuration file in the MS, with periodic update. For some
> > networks,
> > > >>>>over-the-air does not present too much of a problem, when the
> list
> > is
> > > >>>>small. For other networks, the list of roaming CSN IDs could be
> huge
> > > >>>>making over-the-air impractical, so configuration files that
> receive
> > > >>>>periodic update are used.
> > > >>>>Thanks,
> > > >>>>Phillip Barber
> > > >>>>Chief Scientist
> > > >>>>Broadband Wireless Solutions
> > > >>>>Huawei Technologies Co., LTD.
> > > >>>>----- Original Message -----
> > > >>>>
> > > >>>> *From:* McCann, Stephen <mailto:stephen.mccann@ROKE.CO.UK>
> > > >>>> *To:* Gupta, Vivek G <mailto:vivek.g.gupta@INTEL.COM> ;
> Phillip
> > > >>>> Barber <mailto:pbarber@BROADBANDMOBILETECH.COM> ;
> > > >>>> ajayrajkumar@LUCENT.COM <mailto:ajayrajkumar@LUCENT.COM> ;
> > > >>>> Junghoon Jee <mailto:jhjee@ETRI.RE.KR>
> > > >>>> *Cc:* STDS-802-21@listserv.ieee.org
> > > >>>> <mailto:STDS-802-21@listserv.ieee.org>
> > > >>>> *Sent:* Wednesday, June 07, 2006 9:53 AM
> > > >>>> *Subject:* RE: [802.21] Issue #6 Which operator should we
> expose
> > > >>>> in IEs? (doc: 21-06-0667-00-0000_Comment Assignments)
> > > >>>>
> > > >>>> Dear all,
> > > >>>> I would add a word of caution to this, as within IEEE
> 802.11u we
> > > >>>> have assumed that in the future
> > > >>>> there should be no reliance on the association between the
> SSID
> > > >>>> and the access service provider,
> > > >>>> even though it is used in this fashion at the moment. The
> SSID
> > > >>>> should only be considered as a hint
> > > >>>> and does not always indicate who or what you are connecting
> to.
> > > >>>> Currently there are contractual agreements between operators
> > > >>>> (which can vary based on who they
> > > >>>> are - there is no standardised format as far as I know.)
> From an
> > > >>>> 802.21 perspective, the roaming
> > > >>>> agreement itself is not important to the mobile terminal.
> It's
> > the
> > > >>>> fact that one exists that is important.
> > > >>>> Hence I think that 802.21 should not worry too much about
> how
> > > >>>> roaming agreements are expressed.
> > > >>>> Kind regards
> > > >>>> Stephen
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> *From:* stds-802-21@ieee.org
> [mailto:stds-802-21@ieee.org]
> > *On
> > > >>>> Behalf Of *Gupta, Vivek G
> > > >>>> *Sent:* Wednesday, June 07, 2006 3:11 PM
> > > >>>> *To:* Phillip Barber; ajayrajkumar@lucent.com; Junghoon
> Jee
> > > >>>> *Cc:* STDS-802-21@listserv.ieee.org
> > > >>>> *Subject:* RE: [802.21] Issue #6 Which operator should
> we
> > > >>>> expose in IEs? (doc: 21-06-0667-00-0000_Comment
> Assignments)
> > > >>>>
> > > >>>> Seems like we may need two operator identifiers to cover
> the
> > > >>>> general case.
> > > >>>>
> > > >>>> How are roaming agreements expressed? Are they relevant
> to
> > > >>>> only Core Service Providers or to Access Service
> Providers
> > as
> > > >>>> well?
> > > >>>>
> > > >>>> Is this information useful to a MS from a handover
> decision
> > > >>>> making perspective...and are operators generally
> amenable to
> > > >>>> making this available?
> > > >>>>
> > > >>>> Best Regards
> > > >>>>
> > > >>>> -Vivek
> > > >>>>
> > > >>>>
> ------------------------------------------------------------
> > ------------
> > > >>>>
> > > >>>>
> > > >>>> *From:* stds-802-21@ieee.org
> [mailto:stds-802-21@ieee.org]
> > *On
> > > >>>> Behalf Of *Phillip Barber
> > > >>>> *Sent:* Monday, June 05, 2006 12:25 PM
> > > >>>> *To:* ajayrajkumar@lucent.com; Junghoon Jee
> > > >>>> *Cc:* STDS-802-21@listserv.ieee.org
> > > >>>> *Subject:* Re: [802.21] Issue #6 Which operator should
> we
> > > >>>> expose in IEs? (doc: 21-06-0667-00-0000_Comment
> Assignments)
> > > >>>>
> > > >>>> I would say:
> > > >>>>
> > > >>>> Access Service Provider - characterized by providing
> > L1&L2
> > > >>>> level access and may include some authentication
> (device
> > > >>>> authentication; L1&L2 and some L3&L4 capabilities
> > > >>>> negotiation; L1&L2 authentication). Access Service
> > Network
> > > >>>> ID is usually analogous to Operator ID in 802.16 or
> > > >>>> infrastructure based SSID in 802.11. It tells you
> who
> > you
> > > >>>> are connecting to, but not necessarily who is
> > > >>>> authenticating your use.
> > > >>>>
> > > >>>> Core Service Provider- characterized by providing
> L3&L4
> > > >>>> level access and almost certainly includes AAA
> > > >>>> authentication (perhaps device authentication;
> certainly
> > > >>>> user/account authentication; some L3&L4 capabilities
> > > >>>> negotiation). Calling this 'Mobility Service
> Provider'
> > is
> > > >>>> really a misnomer. Calling it the Mobility Service
> > > >>>> Provider is a legacy distinction based on regulatory
> and
> > > >>>> marketing, not technical functional. On a technical
> > level,
> > > >>>> if PMIP, then yes, HA will be in the Core Service
> > Network.
> > > >>>> But the FA is in the Access Service Network and all
> > actual
> > > >>>> mobility activity occurs in the ASN, not the CSN.
> And of
> > > >>>> course the CSN may very well be a visited CSN,
> perhaps
> > > >>>> even likely. Only rationale for calling the CSN the
> > > >>>> Mobility Service Provider is that the Mobile Station
> > > >>>> acquires its IP address from the CSN, if PMIP. If no
> > PMIP
> > > >>>> (CMIP anyone?), it is even clearer. Anyway, mobility
> > > >>>> occurs in the Access Service Network, not the Core
> > Service
> > > >>>> Network. Better to make the distinction based on who
> > > >>>> validates capabilities and authenticates. All should
> be
> > > >>>> viewed from the perspective/perception of the Mobile
> > > >>>> Station. CSN ID is more analogous to ITU E.212 MCC +
> MNC.
> > > >>>> MCC + MNC is not great, but it may be regulated
> anyway.
> > > >>>> May be required to be transmitted to meet regulatory
> > > >>>> requirements. Definitely should stay away from using
> NAI
> > > >>>> over the air. NAI can be huge; very expensive over
> the
> > > >>>> air. And ASN ID and CSN ID could very well be the
> same
> > for
> > > >>>> many networks, especially 802.11 and 802.16
> > fixed/nomadic
> > > >>>> networks.
> > > >>>>
> > > >>>> My two cents.
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Phillip Barber
> > > >>>> Chief Scientist
> > > >>>> Broadband Wireless Solutions
> > > >>>> Huawei Technologies Co., LTD.
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>
> > > >>>> *From:* Ajay Rajkumar
> <mailto:ajayrajkumar@lucent.com>
> > > >>>>
> > > >>>> *To:* Junghoon Jee <mailto:jhjee@ETRI.RE.KR>
> > > >>>>
> > > >>>> *Cc:* STDS-802-21@listserv.ieee.org
> > > >>>> <mailto:STDS-802-21@listserv.ieee.org>
> > > >>>>
> > > >>>> *Sent:* Monday, June 05, 2006 1:10 PM
> > > >>>>
> > > >>>> *Subject:* Re: [802.21] Issue #6 Which operator
> should
> > we
> > > >>>> expose in IEs? (doc: 21-06-0667-00-0000_Comment
> > > >>>>Assignments)
> > > >>>>
> > > >>>> Junghoon Jee wrote:
> > > >>>>
> > > >>>> In my view, "core network operator" loosely can be
> > > >>>> interpreted as the
> > > >>>> "mobility service provider", i.e., the operator that
> > owns
> > > >>>> the user.
> > > >>>>
> > > >>>> Junghoon>> For clarification, the more accurate
> > > >>>> interpretation about the feature of the mobility
> service
> > > >>>> provider is its having a mobility management entity
> like
> > > >>>> HA in case of MIP.
> > > >>>>
> > > >>>> [Ajay] I guess you are treating the "core network
> > > >>>> operator" as the "core transport operator", whereas,
> I
> > was
> > > >>>> in fact treating "core operator" as the "home
> operator"
> > > >>>> including owning HA in case of MIP.
> > > >>>>
> > > >>>> However, if one has to look at the most general case
> of
> > > >>>> the entities
> > > >>>> involved in providing a service to an end host they
> > would
> > > >>>> be as follows:
> > > >>>>
> > > >>>> - Access Service Provider
> > > >>>> - Mobility Service Provider
> > > >>>> - "Services" Provider
> > > >>>>
> > > >>>> Junghoon>> Well, I am not so sure about the above
> > > >>>> categorization.
> > > >>>> I am more inclined to the definition from the IETF
> draft
> > > >>>> that was indicated from the previous message. :-)
> > > >>>>
> > > >>>> Each of the above typically has some level of
> > > >>>> Authentication/Authorization functionality and
> depending
> > > >>>> on the the
> > > >>>> network some of these AA functionalities may be
> optional
> > > >>>> at an implementation/deployment level.
> > > >>>>
> > > >>>> Also, these Authentication/Authorization functions
> could
> > > >>>> be delegated to an independent entity. However, in
> the
> > > >>>> current networks typically this
> > > >>>> is not delegated. Bottomline, the most general case
> > could
> > > >>>> involve six independent entities.
> > > >>>>
> > > >>>> Considering that AA functionality may be integrated
> by
> > the
> > > >>>> provider, three entities may still be involved.
> > > >>>>
> > > >>>> Junghoon>> Back to the main issue of which operator
> > > >>>> information we would expose in IEs...
> > > >>>> I am not still questioning to myself about the
> > feasibility
> > > >>>> and effectiveness of exposing the _core_ operator's
> > > >>>> information to IEs.
> > > >>>> How can a MIH Information Server gather the core
> > > >>>> operators' information depending on the varying
> mobile
> > > >>>> nodes and can pick up the right information for a
> > specific
> > > >>>> mobile node? Do we have to depend on the seed
> > information
> > > >>>> like NAI in case of AAA?
> > > >>>> Moreover, what benefit can a mobile node expect by
> > > >>>> receiving the core operator's information in terms
> of
> > > >>>> seamless handover?
> > > >>>>
> > > >>>>
> > > >>>> Any thoughts?
> > > >>>>
> > > >>>> Best Regards,
> > > >>>> -Junghoon
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
>