Subject: Re: [multimob] Thoughts on Context Transfer

From: <[email-masked]>
Date: Tue, 3 May 2011 10:46:08 +0200

Dear Thomas,
Thanks a lot for your valuable comments - I have to admit that these scenarios are largely 'artificially constructed' and not very realistic - see my comments (marked 'Dirk>' )below.

Regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: Thomas C. Schmidt [mailto:[email-masked]] 
Gesendet: Freitag, 29. April 2011 17:40
An: von Hugo, Dirk
Cc: Gorry Fairhurst; [email-masked]; [email-masked]
Betreff: Re: AW: AW: [multimob] Thoughts on Context Transfer

Hi Dirk,

thanks for your perspectives ... and sorry for the late reply. Please 
see below marked with "Thomas>":

On 20.04.2011 16:35, [email-masked] wrote:
> Dear Thomas et al.,
> Regarding your wish for potential deployment scenarios (of mobile multicast flows handling separated from unicast sessions ... I presume) as below ...
>
>>> Regarding potential use cases for separated HO for multicast traffic (independent of concurrent unicast traffic to the MN) a reason might be operator policy running heterogeneous networks in parallel and doing (multicast) traffic off-load e.g. from cellular (with only few subscribers to a content) to a broadcast medium (e.g. DVB) in case the subscriber group reaches a certain size making it economic to switch the distribution path ...
>
>> O.K., I see. But still this is not exactly a PMIP-like scenario. In your
> case, MN would have to activate an additional radio interface (DVB or
> ??) to receive multicast from there. But this interface would first need
> to configure a unicast IP address before participating in the multicast
> communication. However, this unicast interface would be newly
> instantiated, thus experiences no context transfer, and also lives at a
> different media - so this may be rather a case for MIH??
>

Thomas> Btw. I have discussed this use case with Gorry and he was 
positive about it. Even though this is not a PMIP-like scenario, Gorry 
pointed out that - in particular with DVB-type interfaces - there is 
quite interesting work to do (preparing reception by channel:address 
mapping etc.). Maybe this is something worth working on, as the support 
of cheap broadcast-type link layers may be of interest in future scenarios.

Dirk> I agree that this might be the only realistic scenario - a multi-RAT like ...

>>> AR's in this case may be radio towers ... Spannung a larger area than WiFi and cellular but nevertheless being limited e.g. in case of highway or train movement ...
>
>> I agree, this is an interesting scenario, provided operators do such
> things (or are interested in doing so ???). Still, the problem is a
> different one, in particular for the case of unidirectional downlinks
> such as DVB or satellites or ...
>
>> Even though I would argue that this scenario is something different, it
> might be quite interesting for the group to learn about possible
> deployment options. Will you be able to gather knowledge on this area
> and share with the group?
>
>> Thanks&  best wishes
>
>> Thomas
>
> ... I have tried to finally come up with applications not requiring multiple interfaces, since I agree that this would add too much complexity to our current PMIP based approach.
>
> Nevertheless regarding increasing wireless data traffic forecasts (and popular services with a one-to-many communication structure as in social networks, e-learning, multi-player gaming and so on) operators may seek to save radio resources by replacing several parallel unicast streams by a single (or fewer) multicast streams. E.g. within an urban (WiFi or cellular) network consisting of several access nodes (BS/NodeBs or APs with overlapping coverage which are linked to different MAGs) one of them is taking over the multicast traffic (or even is a 'multicast dedicated' node) - and all MNs which have joined a multicast group are moved to the single multicast stream emerging from that access node - thus requiring decoupled handover for some (or even all) MNs.

Thomas> This scenario would require two independent radio links at the 
MN, one attachment for unicast and the other for multicast. I'm not an 
expert on the capabilities of 3/4GPP radio interfaces at mobiles, but is 
one NIC able to independently connect to two different cells and receive 
independent data in parallel?

Dirk> You are right, it would require muliple NICs and that is very complicated for same radio technology and a handheld since due to interference etc. the antennas have to be located apart - so this is more suited for a router(e.g. NEMO Mobile Router) serving a whole subnet.
 
In any case, we would see two different IP-interfaces at the MN, as well 
... and I still wonder how one of them should be a multicast-only 
interface: even if data streams are sorted by interface for 
load-balancing purposes, one would expect both interfaces to have a 
unicast address, I suppose?

Dirk> Yes, right again - I think each interface or NIC would have to be addressed by separate IP addresses - but since we have IPv6 there should be no shortage ;-)

>
> Similarily the new TV services allowing to switch between different viewpoints (e.g. for sports event transmission) may require to transfer more parallel streams than can be handled by a single access node such that more than one Multicast dedicated access nodes exist. A user switching between different channels may have to be handed over to the 'right' node (and corresponding MAG).

Thomas> This sounds really complicated to me because a mapping of L2 
properties to multicast groups is needed. Either the MN or the cell APs 
(in Network-operated handovers) would need to know which radio connect 
serves which group. However, it may be interesting to think of such 
"inverse" mappings (L2-ID -> mcast-group)?

Dirk> I have to agree ... and no solution idea at hand
>
> Also the differing QoS requirements of parallel unicast and multicast sessions of a MN (related to different services, e.g. mIPTV or video conferencing with low delay vs. file transfer with 0 error probability) may request in case of deterioating link quality to handover only the unicast data session. Accordingly in case of failure of intermediate nodes between LMA and MAG a rerouting may result in unacceptable delay for real-time multicast streaming so that this flow is handed over to a MAG with shorter path delay to the MN (in the scenario with multiple visible MAGs per MN).
>
> At least in current 3G deployment with hierarchical cell structure (HCS) macro cells and overlay micro or pico cells are in operation serving the same area - and thus allowing for the assumed decoupled handover on radio link layer.
>
> At the moment no more different scenarios come to my mind ... And of course these are ideas only and not yet plans of an operator ;-)
>

Thomas> O.K., to sum up my understanding: There may be scenarios for a 
MN to receive Mcast via a different interface than its default unicast 
connect, and this interface may have the same or a different link type. 
MN may be somehow pushed (via its default unicast interface) to activate 
this additional link and configure multicast reception states without 
transferring its unicast default route. Still I cannot see why this 
second interface should work without a unicast address ??

Dirk> I didn't assume that AFAIAAO ...

In the outcome, I see two interesting questions:

  1. How to signal / manage the selection / activation of a new radio 
interface by multicast subscription triggers and how to stir a per group 
state transfer to it? (This is basically the DVB-related question.)

  2. Once the additional interface for multicast reception is up and 
running (incl. a unicast IP address), is there any difference in 
handover operations from a normal "all purpose" default interface? (Or 
isn't it just a second interface that has been select for parts of the 
communication ?).

Dirk> I see no difference to a normal interface but that the network or operator has the chance to dedicate a separate interface to a specific (multicast) service in order to allow for load control or balancing if required or promising advantage (like higher overall throughput or more suited - i.e. also not too high - link quality)

The first question is outside the PMIP domain and not a "standard-type" 
handover scenario that clearly requires new work: this is not solved by 
simply de-synchronizing multicast from unicast ...

Best wishes,

Thomas

>> -----Ursprüngliche Nachricht-----
>> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
>> Gesendet: Mittwoch, 30. März 2011 00:25
>> An: Hitoshi Asaeda
>> Cc: [email-masked]; [email-masked]
>> Betreff: Re: [multimob] Thoughts on Context Transfer
>>
>> Hi Hitoschi,
>>
>> that may be - the first draft to present a context transfer by CXTP
>> independent of unicast handover was
>> http://tools.ietf.org/html/draft-miloucheva-mldv2-mipv6-00 in 2005.
>>
>> The question was about the reasons and the sense behind it ...
>> ... and my reason for asking is that I cannot think of good reasons to
>> do a multicast transfer directly between ARs decoupled from unicast
>> handover.
>>
>> Best regards,
>>
>> Thomas
>>
>> On 29.03.2011 21:20, Hitoshi Asaeda wrote:
>>>> Why don't we use a generic context transfer (by RFC 4067) for
>>>> multicast states only, and leave unicast handover aside?
>>>
>>> As I presented today, our draft uses CXTP (rfc4067).
>>> Regards,
>>> --
>>> Hitoshi Asaeda
>>> _______________________________________________
>>> multimob mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/multimob
>>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °