Subject: Re: [Sipping] Requirements for vertical handover of multimedia sessions using SIP

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 5 Aug 2008 21:48:12 +0200

Dear Ashutosh and SIPPING folks,

thanks for the comments to the draft and to the presentation in
Dublin.

We are for sure willing to give further support to the work on terminal 
mobility (I think we need to consider particular requirements for
"terminal mobility" although we can say that "terminal mobility"
is a kind of subset of "service/session mobility").

Our intention was not to forget about the work that has been already 
done but to stimulate again discussion on this topic (some of the
work on terminal mobility has been already referenced in our draft
but I agree that we need to include more and thanks for giving us
the right pointers) since many solutions are keeping on popping
up.

> However, as I have mentioned earlier, there have been 
> numerous work on Terminal Mobility in the recent years and 
> there is increasingly more interest in this area by the 
> carriers and service providers. Many of us still continue to 
> work around SIP-based terminal mobility area that could be 
> useful to different kinds of deployment scenarios involving 
> single interface, multiple interface, NAT, inter-domain handoff etc.

We think IETF can shed lights on this issue and we are ready
to support a deeper work on the topic. I have received also other
private emails of people willing to contribute to the draft.

In total if we consider the authors of the draft, Henning, you and the
oher people that commented and are willing to contribute, we can say
that there is for sure enough interest (and the SIPPING WG session
hummed to keep on working on this...)
 
> It would be good to see some clear instruction from the 
> SIPPING WG about the direction of the work related to SIP 
> terminal mobility. I am sure there is a task force including 
> me who will be willing to contribute to this effort going forward.

Would be a design team appropriate for the scope? In order to nail
down different approaches, survey a taxonomy of proposed solutions,
and gather a set of requirments that could lead to start work in the
area?

What is the opinion of the group? and of the SIPPING chairs?

Best regards,
Saverio

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Sarker Zaheduzzaman" <[email-masked]>
Date: Fri, 8 Aug 2008 20:44:20 +0200

Hi,

First of all I thank the authors of this draft for bringing up this topic. I support this effort and the proposal of establishing a design team. I am willing to contribute in any way (in drafts or in design team).

Some comments :

# Adjusting the service quality to be optimal might also necessary when there is not change in IP address on a particular AN but there is a inter technology handover in the access network. For example- think about the handover between HSPA to UMTS or to EDGE. The IP address will remain same but the underlying access technologies might change leading to substantial change in available bandwidth/bitrate. The MHs might need to change the session attribute to keep the session alive in this scenario.

# I will also suggest moving the optional requirements number 6 to mandatory requirements. If the session parameters are not renegotiated after the handover or during the handover then the MH may suffer from serious quality degradation resulting drop of call.

Some clarification questions:
# are we only thinking about mid-session mobility (handover during a running session between MH and CH)?

# When a MH registers multiple IP address in the SIP-registrar pointing to same terminal and if the sip-registrar supports forking, for an incoming invite
 the same terminal will get multiple invite thought different ANs. How to handle this king of scenarios without changing UA or SIP servers? 

# while connected though wired technology what are the usecases/scenarios of vertical handover? I am asking this question as I believe wireline connection will produce better matrix of any kind compared to wireless connection. Thus, as long as you are connected to wireline connection it will always be the preferred AN. The only scenario I can imagine is that the user is in rush and unplugs the wireline connection and leaves the current place. In that case I think we will have a little possibilities of handover as the event will be binary. May be you have better scenario then mine. What I am trying to is that in this kind of binary events the handover will only be effective if we maintain simultaneous multiple connections from MH to CH.  

Regards

Zahed

*******************************************
A.N.M. Zaheduzzaman Sarker   
Research Engineer 
EAB/TVK - Multimedia Technologies
Ericsson Research 
Ericsson AB
Box 920 S-971 28 Luleå, Sweden
Tel: +46 (0)8 7573743
ECN: 850-73743
Mobile: +46 (0)761 153743
*******************************************

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Saverio Niccolini
Sent: den 5 augusti 2008 21:48
To: Ashutosh Dutta; Haruki Izumikawa
Cc: SIPPING LIST
Subject: Re: [Sipping] Requirements for vertical handover of multimediasessions using SIP

thanks for the comments to the draft and to the presentation in Dublin.

We are for sure willing to give further support to the work on terminal mobility (I think we need to consider particular requirements for "terminal mobility" although we can say that "terminal mobility"
is a kind of subset of "service/session mobility").

Our intention was not to forget about the work that has been already done but to stimulate again discussion on this topic (some of the work on terminal mobility has been already referenced in our draft but I agree that we need to include more and thanks for giving us the right pointers) since many solutions are keeping on popping up.

> However, as I have mentioned earlier, there have been numerous work on 
> Terminal Mobility in the recent years and there is increasingly more 
> interest in this area by the carriers and service providers. Many of 
> us still continue to work around SIP-based terminal mobility area that 
> could be useful to different kinds of deployment scenarios involving 

We think IETF can shed lights on this issue and we are ready to support a deeper work on the topic. I have received also other private emails of people willing to contribute to the draft.

In total if we consider the authors of the draft, Henning, you and the oher people that commented and are willing to contribute, we can say that there is for sure enough interest (and the SIPPING WG session hummed to keep on working on this...)
 
> It would be good to see some clear instruction from the SIPPING WG 
> about the direction of the work related to SIP terminal mobility. I am 
> sure there is a task force including me who will be willing to 
> contribute to this effort going forward.

Would be a design team appropriate for the scope? In order to nail down different approaches, survey a taxonomy of proposed solutions, and gather a set of requirments that could lead to start work in the area?

Best regards,
Saverio

NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________
This list is for NEW development of the application of SIP Use [email-masked] for questions on current sip Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 09 Aug 2008 16:01:22 +0100

Saverio,

Clearly the biggest use case for this is for handover within or to/from
cellular networks. A prerequisite is that the cellular network supports
IP packet data, e.g., GPRS. However, often quality of service can be
rather poor or unpredictable, and therefore the ability to establish and
maintain a SIP session reliably is questionable, let alone the ability
to perform handover reliably. Do you have any evidence that counters
these concerns?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Saverio Niccolini
> Sent: 05 August 2008 20:48

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 14 Aug 2008 14:48:39 +0200

Dear John,

what you are saying it is true: in our field trials we experienced
problems in quality associated with real-time comunications with
respect to simple ping.

We believe that this is mainly driven by operators' policies of not
willing to have real-time comunications in their network as they steal
revenues...

As soon as real-time communications are allowed by operators and not policed
(adding delays, dropping packets, etc.), then I see no big problem.

Anyway I must say we did not really experienced problems in getting the
signalling through (unless SIP was completely blocked using a firewall on
port 5060), it was more a problem associated with RTP.

Is this what you were referring to? Or you were referring to another
problem I did not get?

Cheers,
Saverio

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Saturday, August 09, 2008 5:01 PM
> To: Saverio Niccolini; Ashutosh Dutta; Haruki Izumikawa
> Cc: SIPPING LIST
> Clearly the biggest use case for this is for handover within 
> or to/from cellular networks. A prerequisite is that the 
> cellular network supports IP packet data, e.g., GPRS. 
> However, often quality of service can be rather poor or 
> unpredictable, and therefore the ability to establish and 
> maintain a SIP session reliably is questionable, let alone 
> the ability to perform handover reliably. Do you have any 
> evidence that counters these concerns?
> 
> John
> 
> > We are for sure willing to give further support to the work on 
> > terminal mobility (I think we need to consider particular 
> requirements 
> > for "terminal mobility" although we can say that "terminal mobility"
> > done but to stimulate again discussion on this topic (some 
> of the work 
> > on terminal mobility has been already referenced in our draft but I 
> > agree that we need to include more and thanks for giving us 
> the right 
> > pointers) since many solutions are keeping on popping up.
> > 
> numerous work 
> > > on Terminal Mobility in the recent years and there is 
> increasingly 
> > > more interest in this area by the carriers and service providers. 
> > > Many of us still continue to work around SIP-based 
> terminal mobility 
> > > area that could be useful to different kinds of 
> deployment scenarios 
> > > involving single interface, multiple interface, NAT, inter-domain 
> > > handoff etc.
> > 
> > We think IETF can shed lights on this issue and we are ready to 
> > support a deeper work on the topic. I have received also 
> other private 
> > emails of people willing to contribute to the draft.
> > 
> SIPPING WG 
> > > about the direction of the work related to SIP terminal 
> mobility. I 
> > > am sure there is a task force including me who will be willing to 
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 14 Aug 2008 14:55:09 +0200

Dear Sarker,

thanks for the encouraging comments and to the support to the idea
of moving this topic forward.

> # Adjusting the service quality to be optimal might also 
> necessary when there is not change in IP address on a 
> particular AN but there is a inter technology handover in the 
> access network. For example- think about the handover between 
> HSPA to UMTS or to EDGE. The IP address will remain same but 
> the underlying access technologies might change leading to 
> substantial change in available bandwidth/bitrate. The MHs 
> might need to change the session attribute to keep the 
> session alive in this scenario.

Right, I see your point. So far our design did not address a single
interface changing IP address, but if we look at the problem from
a more general persective this is a reasonable requirement.

> # I will also suggest moving the optional requirements number 
> 6 to mandatory requirements. If the session parameters are 
> not renegotiated after the handover or during the handover 
> then the MH may suffer from serious quality degradation 
> resulting drop of call.

We will take this into account.

> # are we only thinking about mid-session mobility (handover 
> during a running session between MH and CH)?

that was so far the first use case, why are you asking?

> # When a MH registers multiple IP address in the 
> SIP-registrar pointing to same terminal and if the 
> sip-registrar supports forking, for an incoming invite  the 
> same terminal will get multiple invite thought different ANs. 
> How to handle this king of scenarios without changing UA or 
> SIP servers? 

you may want to check the solution draft we wrote and some of the 
referenced papers, the short answer is that we envision a middle-box
handling the mobility in the network that does this for the MH

> # while connected though wired technology what are the 
> usecases/scenarios of vertical handover? I am asking this 
> question as I believe wireline connection will produce better 
> matrix of any kind compared to wireless connection. Thus, as 
> long as you are connected to wireline connection it will 
> always be the preferred AN. The only scenario I can imagine 
> is that the user is in rush and unplugs the wireline 
> connection and leaves the current place. In that case I think 
> we will have a little possibilities of handover as the event 
> will be binary. May be you have better scenario then mine. 
> What I am trying to is that in this kind of binary events the 
> handover will only be effective if we maintain simultaneous 
> multiple connections from MH to CH.  

If we support forward handover (i.e. the handover procedure is done
on the interface where the connection is moved), you can not
really support call continuity but you can reduce the disruption.

I will discuss with the co-authors and other people and will
try to find a way to move forward this in a more structured way.

Thanks again for your comments,
Saverio

> We are for sure willing to give further support to the work 
> on terminal mobility (I think we need to consider particular 
> requirements for "terminal mobility" although we can say that 
> "terminal mobility"
> Our intention was not to forget about the work that has been 
> already done but to stimulate again discussion on this topic 
> (some of the work on terminal mobility has been already 
> referenced in our draft but I agree that we need to include 
> more and thanks for giving us the right pointers) since many 
> solutions are keeping on popping up.
> 
> numerous work on 
> to support a deeper work on the topic. I have received also 
> other private emails of people willing to contribute to the draft.
> 
> In total if we consider the authors of the draft, Henning, 
> you and the oher people that commented and are willing to 
> contribute, we can say that there is for sure enough interest 
> (and the SIPPING WG session hummed to keep on working on this...)
>  
> mobility. I am 
> Would be a design team appropriate for the scope? In order to 
> nail down different approaches, survey a taxonomy of proposed 
> solutions, and gather a set of requirments that could lead to 
> start work in the area?
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Aug 2008 16:21:56 +0100

Saverio,

I think problems getting RTP transported over cellular are to be
expected for a while, so I was enquiring more about the signalling
(given that there are techniques such as in draft-garcia-mmusic-sdp-cs
that could be used to get round the RTP problem). Thanks for your
answer.

John 

> Sent: 14 August 2008 13:49
> To: Elwell, John; Ashutosh Dutta; Haruki Izumikawa
> Cc: SIPPING LIST
> > you and the 
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: "Sarker Zaheduzzaman" <[email-masked]>
Date: Fri, 15 Aug 2008 11:55:00 +0200

Hi,

>> # Adjusting the service quality to be optimal might also necessary 
>> when there is not change in IP address on a particular AN but there
is 
>> a inter technology handover in the access network. For example- think

>> about the handover between HSPA to UMTS or to EDGE. The IP address 
>> will remain same but the underlying access technologies might change 
>> leading to substantial change in available bandwidth/bitrate. The MHs

>> might need to change the session attribute to keep the session alive 
>> in this scenario.

>Right, I see your point. So far our design did not address a single
interface changing IP address, but if we look at the problem from a more
>general persective this is a reasonable requirement.

I also think that the requirement is reasonable and in the example IP
address does not change on a single interface. Here, I just want to
point out that the adjustment might require even though the IP address
doesn't change.

>that was so far the first use case, why are you asking?

I was thinking of this scenario- if the MH is multihomed and at time T
it is connected to access network A (for example-UMTS) and has no
running session with other MH. Now, at time T+dT it reaches a spot where
it detects AN B (for example -WLAN at home). Then MH might want to
switch to AN B. In this case, the MH has to re-register its new IP
address and ...etc.

But I think this is not a big issue. It will be simple re-registration
procedure with some clever implementation so that the MH does not miss
any incoming call during the switching period. 
 
Regards
 
Zahed
> terminal mobility (I think we need to consider particular requirements

> done but to stimulate again discussion on this topic (some of the work

> agree that we need to include more and thanks for giving us the right 
> support a deeper work on the topic. I have received also other private

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London
W3 6BL Registered in England 2832014

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 15 Aug 2008 14:13:13 +0200

Dear Sarker,
 
> >> # are we only thinking about mid-session mobility 
> (handover during a 
> >> running session between MH and CH)?
> 
> I was thinking of this scenario- if the MH is multihomed and 
> at time T it is connected to access network A (for 
> example-UMTS) and has no running session with other MH. Now, 
> at time T+dT it reaches a spot where it detects AN B (for 
> example -WLAN at home). Then MH might want to switch to AN B. 
> In this case, the MH has to re-register its new IP address and ...etc.
> 
> But I think this is not a big issue. It will be simple 
> re-registration procedure with some clever implementation so 
> that the MH does not miss any incoming call during the 
> switching period. 

Right, in our implementation we have also this clever 
agent that makes sure the MH does not miss the call and updates accordingly 
the registration contact.

Saverio