RE: [802.21] Network Controlled Handover and IS
Vivek,
-----Original Message-----
From: ext Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
Sent: Wednesday, August 24, 2005 09:01
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Network Controlled Handover and IS
Some comments below..
_____
From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of zze-Seamless PERESSE M ext RD-RESA-REN
Sent: Wednesday, August 24, 2005 5:29 AM
To: STDS-802-21@listserv.ieee.org
Subject: 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...).
[Vivek G Gupta]
Many of the existing media specific technologies already do this in some form. For example 802.11k provides access to link layer measurements like Bit Rate, BER, etc. that you mention above. Other media specific technologies also have a provision for something similar.
Given that, do we need any additional methods/primitives or capabilities from 802.21 for above?
[[Stefano] ] I think the answer is completely depending on the use scenarios. Let's assume a 3GPP network operator owns multiple accesses, such as 802.11 and 802.16 in addition to the 3GPP specific access networks. Let's assume the operator is interested in having network controlled HO e.g. for load sharing or other reasons that require stricter control that the one granted by simply controlling the policies in the terminal used to decide HO between technologies. In such case, it may be difficult in practical implementations to have an MME function in the network that relies on existing L2 technology-specific to collect the information. it pretty much implies a tight IW of the various radio interfaces/ANs at L2, that may not be that easy to implement nor that acceptable to 3GPP operators/vendors. In such scenario, using 802.21 at "L3 and above" to allow reporting of information to the MIHF in an MME that is used to control inter-technology HO may be an easy and clean way to!
go. I see this as a very relevant scenario for "L3 and above" MIH.
As for application needs and user preference, we may need additional primitives for client <> network communication.
[[Stefano] ] indeed
It would be good to identify these specific requirements and then we can see if that needs to be specifically addressed by 802.21 or through some other means.
Again these are probably not part of Information Service as we have described.
[[Stefano] ] I agree with you. interested parties should identify the use cases in detail and bring them forward to identify the specific requirements. Also, I agree this is not part of IS.
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...) .
[Vivek G Gupta]
Maybe we can keep this part separate from Information Service, since the way we have described IS, it deals mostly with static type information that is not changing very rapidly and IEs that change dynamically may need to be addressed in a different manner.
Measurements seem to be handled by individual access technology and if we identify any gaps in what is already provided we can always add that as access technology specific amendment.
Do we need to abstract measurements from 802.21 perspective?
[[Stefano] ] good question. perhaps not, but I think we need to think about this a bit more.
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
_____
De : Eunah Kim [mailto:eakim@etri.re.kr]
Envoyé : mercredi 24 août 2005 12:17
À : STDS-802-21@LISTSERV.IEEE.ORG
Objet : Re: [802.21] Meeting minutes of today's ad-hoc teleconference
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