| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ulises,
thanks for your comments.
Please see my answers below :
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. [[MP]] I am well aware that CS and ES
are suited for handover concerns. In my previous email I was talking about
Information Elements an UE could transmit to an MME in order to select the best
PoA for that UE (that is the first procedure in a Network Controlled HO, the
second would be the order itself..). I wasn't talking about HO
decisions/command. I wanted to express how IS could be of help if we
consider Network Controlled Handover. The Information Exchange scheme won't be
the same in the case of a terminal driven HO or in the case of a Network
driven HO...
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. [[MP]] OK... But, at least semantically, I don't think a Measurement Report can be considered as an "Event" by itself... For me, it's more an "Information" ;-) Furthermore, if we use Link Parameter Changes for Link Parameters we should also introduce an "Application Parameters Change" event (for QoS needs change upon a new app launch on the terminal) and possibly a "User Preference List change" event (when a user changes its allowed list of network / technologies / cost limit......). That's what I can think of, maybe there are more...
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 >> |