Network Controlled Handover and IS
Hi all,
I would like to open a discussion about Network
Controlled Handover (which has to be covered by 802.21) and
IS:
The Information Service reference model we've discussed
yesterday introduces an Information Database, a network MIH IS function and a UE
MIH IS Function.
The main idea in these slides is that the UE MIH
IS function will gather the Information Database through the Network MIH IS
Function.
This is convenient when dealing with Terminal
Initiated/Controlled Handover: the terminal gathers information about its
environment and decides to which PoA it should
handover.
But for a Network Controlled Handover, the terminal
doesn't need to know much about its environment. Instead, a Mobility Management
Entity (MME) (probably embedding a MIH function) located in the
network should gather information about the UE environment and decide if and on
which PoA the UE has to be handed over.
So I
guess another use case is needed, where the UE would transmit Information
Elements through IS such as (SNR, BER, Signal Level, Bit Rate, User
Preference, Applications QoS Needs...) to a MME (possibly linked to an
"Information Database" similar to the one introduced on the
slides...).
That
implies that we introduce an ".indication" primitive in the IS primitive set.
Also,
that imply that we agree that IS does not exclusively transfer "static
information" but also "dynamic information" (SNR, BER, Signal Level, Bit Rate,
User Preference, Applications QoS Needs...) .
In the
draft, the only means to transfer this kind of Information is through the
"MIH_Poll.request/response" primitive, which is a Command... I don't think this
is very practical, as the MME would have to regularly make a
MIH_Poll.request to UEs, to get up to date values of the various
parameters....
Finally that would imply a disctinction between an
UE Information Element Set (to be sent to an MME/InfoDatabase...TBD) and a PoA
Information Element Set (IEs to be transmitted to the UE on demand - these IEs
are the ones currently defined in the draft).
Looking forward to your comments
Rgds,
Mat
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.
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.
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