Re: [STDS-802-16-MOBILE] [Handoff] Location Update issue
Phil and all,
I added more detailed explanation into my presentation below with [YONG]
Please catch what I try to do here.
Thanks,
Yong
----- Original Message -----
From: "Phillip Barber" <pbarber@broadbandmobiletech.com>
To: <STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
Sent: Tuesday, June 22, 2004 11:52 PM
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Location Update issue
> Yong Chang and all,
>
> I am sorry Yong Chang, but it is not clear to me from your email what the
> problem statement is and what the proposed alternative solutions are.
While
> we have been discussing this directly and I am aware of your proposal, I
> thought that, given that it is difficult for me to decipher your proposal
> from the email, others might be similarly confused. Perhaps you could
> clarify your presentation.
>
> Thanks,
> Phil
>
> ----- Original Message -----
> From: "Yong Chang" <yongchang@SAMSUNG.COM>
> To: <STDS-802-16-MOBILE@listserv.ieee.org>
> Sent: Tuesday, June 22, 2004 4:54 PM
> Subject: [STDS-802-16-MOBILE] [Handoff] Location Update issue
>
>
> > Hi, all
> >
> > We identified the following issue with location update in idle mode
within
> > the Handover AdHoc.
> > The following issue is raised.
> >
> > Basic assumption behind this issue are that
> > - The MSS does not need to perform all network entry procedure when it
> wants
> > to update his location only.
> > That is, MSS does not need to perform SBC/PKM/REG after the
successful
> > location update.
[YONG] Whenever the MSS detects the change of paging group or the timer is
expired,
the MSS trys to update his location. If the MSS wants to update his location
and enters the idle mode directly,
it is natural that the MSS does not need to perform all procedure of network
entry procedure like SBC/PKM/REG.
> > - The network entity(e.g., BS ID or ASA ID) is required to indicate what
> > network entity stores
> > MSS's location information and security information in idle mode.
> >
> > There are two approaches here.
> >
> > 1. RNG-REQ includes the action code for location update(2bits), HMAC
> > tuple(176bits), and Server ID(48bits, the server stores
> > the location information, idle mode authentication key, etc)
> >
[YONG]
If RNG-REQ is used for the MSS location update by adding some TLVs into
itself, the current RNG-REQ shall include
at least some information described above.
> > * Cons
> > This approach may cause a problem for the BS to assign a bandwidth to
the
> > MSS when it sends RNG-REQ because the message size of RNG-REQ is varied
on
> > multiple cases: initial ranging, periodic ranging, handover ranging, BW
> > request ranging, and even location update ranging.
[YONG]
If RNG-REQ includes some new TLV informations, the message size of RNG-REQ
on initial ranging is dynamically varied
for the multiple usage cases: Connection Setup, Location Update, etc. That
is a problematic because the BS shall provide the
maximum bandwidth for RNG-REQ to cover all usage cases. Eventually, BS may
waste his resource.
> >
> > * Pros
> > This approach uses the current RNG-REQ/RSP messages.
[YONG] No new message.
> >
> > 2, RNG-REQ includes the indication bit for location update purpose. New
> > management messages LU-REQ/RSP with HMAC tuple, Server ID.
> >
[YONG]
In order to skip the unnecessary network re-entry procedure like
SBC/PKM/REG, RNG-REG needs to include the location update indication bit.
After MSS and BS exchange RNG-REQ/RSP, new management messages
Location Update REQ message with HMAC tuple, Server ID, etc is sent from the
MSS. After the successful location update at the BS, BS sends Location
Update RSP message.
> > * Cons
> > This approach is to make a new MAC management messages for location
> update.
> > New 1 bit in RNG-REQ is overhead even if it is not severe.
[YONG]
Current RNG-REQ shall include new TLV for location update purpose 1 bit.
This is at least 3 bytes(Type 1 byte,
Length 1 byte, indication bit 1 byte with reserved 7 bits) overhead.
However, this overhead is inevitable.
New Location Update REQ/RSP messages are required.
> >
> > * Pros
> > This approach adopts the current initial ranging mechanism with 1 bit
> > indication of Location Update. There is no problem for the BS
> > to assign the bandwidth to the MSS when it sends the RNG-REQ.
> >
[YONG]
Since the RNG-REQ includes AAS Broadcast Capability 1 bit as TLV,
the location update indication 1 bit can locate together. Therefore, no
problem to the BS on bandwidth assignment for RNG-REQ.
> > Any comments?
[YONG] I want to socialize this issue within handover ad hoc. Which
mechanism is better?
> >
> > BR,
> >
> > YONG CHANG
> >
> > Senior Engineer/Ph.D
> > Samsung Electronics Ltd.
> > Tel: +82-31-279-3621
> >
>
>