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