Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] Ad-hoc Teleconferencec on Communication Model - October 18, 2005



> -----Original Message-----
> From: Srinivas.Sreemanthula@nokia.com
> [mailto:Srinivas.Sreemanthula@nokia.com]
> Sent: Tuesday, October 18, 2005 7:22 AM
> To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> Cc: stefano.faccin@nokia.com
> Subject: RE: [802.21] Ad-hoc Teleconferencec on Communication Model -
> October 18, 2005
> >>
> >> >If a UE is connected to a single L2 link can we have a MIH
> >PoS in PoA
> >> >and possibly another L3 MIH PoS somewhere else in the network?
> >> >If a UE is connected to multiple L2 links how is a MIH PoS at
> >> >L3 associated with a network w.r.t above restriction?
> >>
> >> My thought was that the UE may not receive CS from multiple MIH
> >entities
> >> and UE cannot decide on the info authenticity if there were
multiple
> >> sources of IS. I agree with you that there is a possibiliy
> >that these
> >> MIH services can be shared between L3 and L2 MIH entities.
> >But it must
> >> be in a way that they are not conflicting in the offered services.
I
> >> think we should capture this. I was thinking about stating
> >generically
> >> that multiple MIH PoS can provide partial MIH services (IS,
> >ES and CS)
> >> but the provided (partial) services in such a way they are not
> >> conflicting with other services offered by other MIH PoS.  How does
> >this
> >> sound?
> >
> >[Vivek G Gupta]
> >...not very convincing.
> >It should be left to UE and MIH enabled network entities (MIH
> >PoS) to discover each other, decide and negotiate an
> >association. Given that there can well be multiple instances
> >of such associations and it would be up to the UE to select
> >and sign up for appropriate services for each association and
> >also possibly deal with multiple instances of such
> >associations and individual services.
> >Maybe this needs to be better explained in doc. I don't have
> >any good practical scenarios though.
> >
> Srini)) I need to understand you better. My question is - why would a
UE
> have two IS providers (MIH PoS) in the same network providing same
> information?  Why would the UE receive the same CS from two different
> MIH PoS? If so, which one is authentic?
> 
[Vivek G Gupta] 
Again I don't have any practical scenarios. 
But hey, let's just say that because of some deployment or other
difficulties the IS within a network could be split with one MIH PoS
providing info about certain access networks and another MIH PoS
providing info about certain other access networks, etc.
There could be other examples as well, or maybe not, but for now we may
be better off not putting this slightly restrictive statement in doc.



> >>
> >> >Also even if the above restriction is true how shall it be
> >> >enforced/applied?
> >> It can be done in several ways. E.g. Info in discovery
> >mechanisms can
> >> say what specific MIH service capabilities are on a given given MIH
> >PoS.
> >>
> >[Vivek G Gupta]
> >Sure but can you prevent UE from making multiple associations
> >with multiple network side MIH PoS. If not then IMO the above
> >cannot be enforced/applied.
> >
> We are not restricting in the number of MIH PoS associations from UE,
it
> is the capabilities on that association is what is of interest. We are
> trying to avoid the duplication on that capabilities. If you think we
> need it, some useful scenarios can help us understand. The enforcement
> is automatic, in the sense that the MIH entities know what they are
> providing.
> 
[Vivek G Gupta] 
I agree with you. We can leave it to MIH entities to decide what kind of
associations they want to setup and how they want to use these services.
Hopefully they are smart enough to avoid duplication of a service. Given
that the issue of having single/multiple associations within a network
can automatically be dealt with and we need not say anything explicit
about that. "Less is more" here in the sense by putting fewer rules we
enable larger number of possibilities (if and when they arise).

Best Regards,
-Vivek