| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Attendees:
Jing Wang (jwang@ztesandiego.com)
Beomjoon (BJ) Kim (beom@lge.com)
Yong-Ho (Ronny) Kim (ronnykim@lge.com)
Chang-Jae Lee (cjlee16@lge.com)
Chulsik Yoon (csyoon@etri.re.kr)
Sung-Cheol Chang (scchang@etri.re.kr)
Jaesun Cha (jscha@etri.re.kr)
Seokheon Cho (chosh@etri.re.kr)
Min-Sung Kim (cyberk@kt.co.kr)
David Johnston (dj.johnston@intel.com)
Chris Seagren
(chris.e.seagren@mail.sprint.com)
Mary Chion (mchion@ztesandiego.com)
Phillip Barber (pebarber@broadbandmobiletech.com)
Jung-won Kim (jungwon74.kim@samsung.com)
Changhoi Koo (chkoo@samsung.com)
Jung Je Son
(jungje.son@samsung.com)
Yong Chang
(yongchang@samsung.com)
Dongkie Lee
(galahad@sktelecom.com)
Nat
natarajan (nat.natarajan@motorola.com)
Prakash Iyer (prakash.iyer@intel.com)
Proceedings:
* We started by reviewing and updating a categorized
list of the latest contributions for handoff adhoc group consideration (list
follows below with updates based on discussions from day 1).
Flags and definitions for
different levels of HO context sharing
Category covers mapping of flags to network (re)entry functions that can
be skipped/optimized, negotiation between MSS and BS and context information
shared at each level
Contributions discussed: HO optimization flags, 87r2, overhead reduction for initial ranging, 04/61 (ARQ state transfers), 04/65 (channel number assignment during HO), 105_Enhanced HO reentry, 76r2, 90r2, 105_Inter-sector HO rev1
Following discussions, the group agreed to:
- Take Phil Barber's HO
optimization flags contribution and harmonize with 87r2 and concepts from 04/61
(ARQ state transfers), 105_Enhanced HO reentry, 76r2 and 90r2.
- Withdraw 04/65 as concepts were
adequately addressed by harmonization of other contributions
- Defer overhead reduction for initial ranging to a
later conference call as contributions authors were absent
Quick summary of harmonization changes (Phil to create harmonized contribution for upload):
- Converge on use of Flags instead of
levels for different HO context sharing scenarios
- HMAC Tuple in RNG-REQ (Need clarification from security
adhoc)
- Add HMAC Tuple to RNG-RSP
- Incorporate flags into HO RSP messages
per 105_Enhanced HO
reentry
- Propose a flag in SBC-REQ in RevD to indicate no
support for extended TLV in RNG RSP and appending of SBC-RSP and REG-RSP data as
TLV items (process to be discussed with RevD folks)
- Add text to RNG-RSP to describe optional
appending of SBC-RSP and/or REG-RSP TLVs into RNG-RSP
- Add a flag in RNG-RSP indicating pending DL
traffic from serving BS to target BS (from 76r2) - bit #7 in HO process
optimization TLV
- Change the language in Optimization Flag
TLV to clarify that it is ‘may’ for MSS REQ side only.
- Add a HO Indication TLV item into RNG-REQ; make
appropriate language changes in HO Process and throughout document to reflect
the fact that this is how target BS gets notified of start of HO. Make sure
language is specific that RNG-REQ TLV items can only be included in specific BW
request ranging opportunties.
- Full service and operational state transfer flag - bit #6 in HO process optimization TLV (ARQ, timers, counters, MAC state machines)
- Informative HO call flow diagram
NOTE to Security adhoc - Please examine use of HMAC Tuple in RNG-REQ and RNG-RSP
Samsung request (pending broader discussion): Would prefer to use flags negotiated in RNG-REQ and RNG-RSP to retain MSS context even in Idle mode. This will need some notion of context aging timer. Needs input from security adhoc group.
Concern raised - How does the BS know how much bandwidth to allocate for RNG-REQ to accommodate HO indication TLVs - should it allocate BW for all TLVs all the time? ETRI has a new proposal - code base ranging indication flag that could be used to optimize bandwidth allocation for RNG-REQ/RSP. This is only applicable to OFDMA. To be discussed over the reflector.
Deferment of IP address
assignment
Contribution 76r2
was discussed. Group noted that deferring
establishment of an IP address following a HO can be handled as an
implementation detail. For example, if a deployment scenario were to support
data forwarding (via tunneling) from the serving BS to the target BS during HO,
then the target BS will suppress IP layer indications such as router
advertisements from reaching an MSS until it is OK to do so (i.e. after
notification from serving BS that it has no more data to forward). This is
partial resolution of 90r2.
Context retaining and
release during a HO procedure
In this category, we discussed 3 contributions that relate to how long a
serving BS should retain context information of an associated MSS (to support
situations such as drop recovery) and when it is OK for the serving BS to
release such context following completion of the HO procedure.
Contributions discussed: 55r3, MSS release after completing initial network entry and Clarification of drop situation after HO procedure.
Following discussions, it was decided that that the 3 contributions will be harmonized (Changhoi to lead effort) with changes as under:
- Provide text to clarify the notion of
context aging timer
- In section
6.3.20.2.3 add some text to clarify that HO cancel to a serving BS implies that
the MSS will resume normal operation with that BS
- Accept changes in text from 6.3.20.2.5 from MSS release after completing initial network entry - undeleting text that was marked for deletion in blue and accepting new text in red
- I-am-Host is a periodic (no specific event triggered) broadcast message between BSs to update with information of associated MSS. These contributions introduced 2 new indications - HO Complete and HO Post Confirm. Drafting team will look into eliminating the 2 new HO indications and extending the semantics of I-am-Host to accommodate this indication requirement
Definition of IDs such as
BS ID, operator ID, sector ID and channel number (FA ID)
In a HO there are 2 changes that an MSS needs to
know:
- When PHY context
changes
- When MAC context
changes
We decided to keep to the definitions of BS ID (48-bit identifier). We decided not to impose any semantic restrictions on the use of BS ID. For example, a multi-sector BS in the real-world might use a different BS ID for each sector line card. That will be accommodated by this standard.
Changes to NBR-ADV are as follows:
- Changed the semantic meaning of
neighbors to mean the unique combination of Neighbor BS ID, preamble index and
DCD.
- Deleted DL Physical
Frequency (as it is already captured in TLV encoded information)
- HMAC Tuple was deleted as message is
broadcast
- Added separate DCD and
UCD configuration change counts
-
Added Preamble Index as it helps with scanning and SHO. It is only applicable
for SCa and OFDMA.
- Added Length
field to indicate TLV length for each loop instance
- Added a new 16-bit place-holder for PHY settings.
Values are TBD.
Format for NBR-ADV that the group agreed to is included below.
Syntax Size
Notes
MOB_NBR-ADV_Message Format(){
Management Message Type =49 8 bits
Operator ID 24 bits Unique ID assigned to the
operator
Configuration Change Count 8 bits Change
count for this message
N_NEIGHBORS 8 bits The count of the unique
combination of Neighbor BS ID and Preamble Index and
DCD
For (j=0; j< N_NEIGHBORS; j++){
Length 8 bits Length of
message information within N_NEIGHBORS loop in
bytes
Neighbor BS ID 24 bits
PHY Profile ID 16 bits
TBD
HO Process Optimization 8 bits
Preamble Index 8 bits SCa
and OFDMA PHY specific only
DCD Configuration Change Count
8 bits This represents the Neighbor BS current DCD configuration change
count
UCD Configuration Change Count
8 bits This represents the
Neighbor BS current UCD configuration change
count
TLV Encoded Neighbor
information variable
TLV
specific
}
}
HO scenario
definitions
No new definitions
are being proposed. All HO scenarios (intra-BS, inter-sector, inter-BS,
inter-sector etc.) will be modeled via the same call flow model. Appropriate use
of Flags in NBR-ADV and RNG-RSP will determine the level of HO context sharing
between the serving and target BS.
Soft HO and Fast BS
Switching
As we do not have
quorum at the F2F, we decided to defer harmonization to on-going offline
discussions between ZTE, Nortel, Runcom, Samsung and others. On day 2, Mary will
summarize progress to date to the F2F team. The SHO/FBSS team will make an
attempt to harmonize their respective contributions by 6/25. Samsung also
mentioned that they will have a new contribution on FBSS on 6/21.
Harmonization update will be discussed during our Thu conf call.
Scanning
Optimization
Only contribution
that was discussed: A method for scanning neighbor BS periodically - rev
2
Following discussions, Ronny Kim will
revise the contribution incorporating the following changes:
- Text to indicate how scan iterations could be
aborted / canceled after MSS negotiates this number with a serving BS
- Submit a technical binding comment to
propose reduction of scan duration to 8 bits from 12 bits
- Ensure SCAN-REQ/RSP fields are byte aligned
Group also noted that some text is needed in .16e to discuss negotiation of capabilities and determine if MSS or BS initiated HO will occur in a system.
Plans for Day
2:
* Review updates to
harmonized contributions and decisions from Day 1
* Upload revised contributions for handoff adhoc
group review; publish logistics for telecon on Thursday, 6/24
* Summary review of SHO/FBSS harmonization
* Discuss following contribution categories
not covered / completed on Day 1:
-
Harmonize changes to NBR-ADV
-
Minimizing IP connection establishment - Contributions include: Minimization of
IP connection reestablishment_r1, 68r2, 90r2, 51r1
- Idle mode HO optimization - Contributions include: 66r1, 04/108-Enhanced Idle mode operation, 04/28r1, 04/105-Complementing Idle mode HO operations
- Ping pong support
- Safety channel HO procedure
- Session state lifetime on BS (continue from day 1
+ 48r1, handling session context in Idle mode)
- Association optimization (04/57)
- Changes to informative SDLs in Annexes
Deferred to Security
Adhoc:
- Skipping / optimizing
PKM (04/50r1)