Re: [802.21] Meeting minutes of today's ad-hoc teleconference
Hi Eunah,
I think your point is valid. Please see my comment below.
On Wed, Aug 24, 2005 at 07:16:47PM +0900, Eunah Kim wrote:
> Hi Yoshihiro,
>
> Thanks for your clarification.
>
> >> By the way,
> >> when will it be the case of (1:n)?
> >
> > An UE attached with only one NISP can communicate with multiple IS
> > Functions within the NISP, if the information databases are
> > distributed in the NISP. An example is that XML/RDF databases can be
> > distributed similar to DNS.
> >
> It seems like rather implementation issue
> We are considering the interface between IS functions in the UE and in the network
> and I think the term NISP is adopted to be used as the peer concept of the UE.
> Thus, if we assume that there is one IS function in the NISP,
> it will be a lot simpler and easier to understand.
I understand your point, and I agree with you that we can assume only one
IS function per NISP under the concept of UE-NISP peering.
>
> BTW, does indicating the relationship(1:n) have an effect on making requirements?
> If not, why don't we leave it out from the reference model and all Use-Cases.
I agree that we can remove all (1:n) tags from the entire slides,
given that explicit text stating "an IS Function and an Information
Database may be implemented in a distributed manner" is added
somewhere in the document for clarification.
Regards,
Yoshihiro Ohba
>
> Regards,
> Eunah
>
> >>
> >> My understanding is that one UE can communicate with only one NISP at a moment.
> >> The reason for having (1:n) would be the case that the UE moves so needs to connect
> >> with a different NISP from the previous one. Am I right?
> >
> > Yes, the multi-NISP case is one obvious reason. There can be other
> > reason as I described above. BTW, I think the current reference model
> > does not seem to preclude the case in which one UE communicates with
> > multiple NISPs at a moment, as the model just defines interfaces. We
> > can discuss this level of details in the process of identifying actual
> > requirements.
> >
> > Hope this helps,
> >
> > Yoshihiro Ohba