| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mat, See comments below. Regards, Ulises From: zze-Seamless
PERESSE M ext RD-RESA-REN [mailto:mperesse.ext@RD.FRANCETELECOM.COM] Hi all, I would like to open a discussion about
Network Controlled Handover (which has to be covered by 802.21) and IS: We need to make a distinction between
system discovery and selection and handover. As stated in the current 802.21
draft, 802.21 provides three main services, namely Command Service (CS), Event
Service (ES) and Information Service (IS). The IS provided is better suited for
the system discovery and selection as it might not always meet stringent requirements,
imposed by the need to handover while providing real time services. One the
other hand, ES and CS are better suited for handover applications. 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. As indicated above this is function falls
under events and commend services. A mobility management entity like the one
you describe above, can subscribe to 802.21 events and generate 802.21 commands
or use exiting intra technology command to trigger a handover. 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...). I believe this use case is valid, only
that is not part of the 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...) . Please see comment above. 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.... The draft also provides the means to
indicate when the value of a relevant parameter has changed through a Link
Parameter Change event.. This includes parameters such as BER, FER, RSSI and
bit rate. Even though we might still need to review this list and addition/modification
might be appropriate, this is the vehicle that 802.21 provides to flag real
time parameter value changes such as the ones you proposed above. 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 >> |