Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 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? As for application needs and user preference, we may need
additional primitives for client <> network communication. 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. 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? 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] Hi Yoshihiro, Thanks for your clarification. >> By the way, 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 >> |