| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Mat, Some more comments below. Thanks, From: zze-Seamless
PERESSE M ext RD-RESA-REN [mailto:mperesse.ext@RD.FRANCETELECOM.COM] 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... [UO] I believe your are stressing the
bidirectional nature of the IS. This is a valid point. Although this wasn’t
precluded in the slides presented yesterday. If we indicate that the
information exchange is bidirectional and asymmetric this should satisfy the
need express above. Please comment. 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... [UO] As I indicated, above if we see the need
to add more parameter, we should propose it. I believe the current list could
still be improved. Your e-mail is a good way to motivate a discussion leading
to a complete list. One think to keep in mind (although is probably obvious) is
that the list of IE required for ES and IS will not necessarily be the same and
as such it might be better to hold separates discussions. 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 >> |