Subject: Re: [multimob] Thoughts on Context Transfer

From: <[email-masked]>
Date: Wed, 20 Apr 2011 16:35:20 +0200

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??

>> 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.

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).

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 ;-) 

Best regards and happy holidays!

Dirk
> -----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 °

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 29 Apr 2011 17:39:35 +0200

Hi Dirk,

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

> 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.

>> Thanks&  best wishes

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?

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?

> 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 acc…

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)?

> 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 ??

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 ?).

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

--