Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon



Ronny,

My answers are in-line.

Branislav

>
> 1. Can MSS always acquire FQDN without any exception?
> (Even in case of using Mobile IP?)

Yes, DHCP can be used as indicated in conjunction with Mobile IP.

> 2. Why IP address is required along with FQDN for the target
> BS to make
> decision of IP re-
> establishement?

The IP address would be passed from the BS to the Gateway Access Router (GAR). The IP address may be used by both the BS and the GAR. This allows for explicit (as opposed to just simply tunneling the MSS's IP packets to the GAR) handover handling by the BS and the GAR and also different types of policy settings at the GAR.

> 3. What are the references regarding FQDN setting in routers?
> (I have searched DHCP documents such as RFC 1533, 2131, etc
> and Mobile IP
> documents, but I
> couldnĄŻt find any information.)

To see how the FQDN is used in conjunction with DHCP see:
RFC 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option
or
RFC 3495 Dynamic Host Configuration Protocol (DHCP) Option
for CableLabs Client Configuration
or
just the DHCP FQDN client option.

Within the HO context, the GAR FQDN is communicated as a DHCP option to the MSS and then from the MSS to the target BS, The target BS can then use the GAR FQDN to connect to the GAR or decide whether to connect to it or not based on a policy setting. In any case it uniquely identifies the source GAR which currently handles the MSSs IP traffic and enables the target BS to make a decision on whether the MSS needs to renew its IP address or not.

>
> I still need more information and time to make decision that this is a
> right solution.
> However, if Ad hoc people agree on using FQDN and MSSĄŻs IP
> address for IP
> re-establishment
> decision, this document can be harmonized.

OK

> If the serving BS can have FQDN of GAR as the target BS does,
> and if the
> serving BS knows MSSĄŻ
> s IP address and sends FQDN and IP address to the target BS
> over a backbone
> then this would
> work.  (If IP address is not required, the solution would be
> much simpler.)
> Therefore, if MSS can send its IP address to the serving BS before
> completion of HO procedure
> with the serving BS (maybe in MOB-HO-IND, or new MAC
> message), then the
> serving BS send them to
> the target BS through a backbone and the target BS makes
> decision and sets
> HO Optimization flag
> bit #3.
> The reason why I suggest that the MSS send its IP address
> before HO is ad
> hoc people have
> agreed on HO optimization.
> Based on this optimization RNG-REQ is the place you put your
> parameters
> such as GAR-FQDN, MSS-
> PREV-IP-ADDR, but for many reasons we can not put more
> massive information
> in RNG-REQ.

These ideas are good but the solution proposed here is intended mainly for the situation where there is no (or no easy and inexpensive) connectivity between the serving and target BS. BS/source GAR connectivity does not use any additional, possibly scarce, RAN backhaul resources. It simply relies on the core network connectivity which most of the time is abundant and inexpensive.

Therefore, this solution adds a whole new set of deployment possibilities with simpler connectivity.

Please let me know whether this clarifies your questions and whether you agree with the proposal.

Thanks,

Branislav


>
>
>
> Thanks,
>
> Ronny
>
> ________________________________________
> From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-
> mobile@listserv.ieee.org]
> Sent: Friday, July 02, 2004 6:49 AM
> To: STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon
>
> As a follow-up to the action item below, we received and incorporated
> comments from Phil. Does
> anybody else have comments on C80216e-04_151r1.
>
> Thanks,
>
> Branislav
>
>  * C80216e-04_151  Minimizing IP Connectivity Delay During Network
> (Re)Entry
> Ran out of time, did not discuss. Authors to solicit input on
> the mailing
> list.
>