QC/ZTE/CT proposal

1. QC/ZTE/CT proposal • Qualcomm/ZTE/CT proposal (C22-20110523-013) • Expand the functionality of RouteUdpateRequest message and RouteUpdate message to include E-UTRA channel information • Indicated the proposal can achieve load balancing • When AN request reporting of E-UTRA channel info from UE, the RouteUpdateRequest message can not include HRPD neighboring channel info (i.e. SectorCount = 0), and this request message is only for requesting E-UTRAN channel information from UE. • Expand the Redirection message to include EUTRA channel for redirection. • Issues • The RouteUpdateRequest message is unicast message, it is not efficient for the purpose of load balancing. • If RouteUpdateRequest message can not request channel information from more then one RAT, why use RouteUpdateReqeust message? • No option on supporting autonomous reporting on other RAT channel info • Extend Redirect message is ok but not very clean. • Unicast Redirect message can not achieve load balance efficiently

2. Suggestions (1) • Instead of overload RouteUpdateRequest/RouteUpdate message pair, use new message pair for reporting other RAT channel information. This is for the purpose of unicast redirection. • For example using new message such as OtherRATPilotReportRequest/ OtherRATPilotReport message pair for the purpose of reporting other RAT’s channel information • The request is sent by AN with the intend to redirect the UE to different RAT • Clean structure and can support multiple system types. • Possible fields to be included in the request message: • RAT system type info • E-UTRA channels to be reported (optional) • minimum reporting threshold information such that UE only report EUTRA channel meet this (optional) • OtherRATPilotReport message: • RAT system type info and channel blob records for that particular RAT type. • For C.S0087, only RAT type addressed is the EUTRA, but the format should support multiple RAT types.

3. Suggestions (2) • UE should have the option to send an OtherRATPilotReport/RouteUPdate message autonomously • AT knows the best when it can see an E-UTRAN channel with good signal quality. • Need some guidelines set by AN if autonomous method is enabled: • Minimum reporting threshold: only EUTRA channel with signal pilot threshold above this level can trigger the reporting • HRPD trigger threshold: UE may sends the autonomous OtherRATPilotReport message when all the HRPD channel signal strength below this parameter • ReportOnActiveState: reporting can be enable only for UE at active state • ReportingInterval: use for the purpose to prevent frequent autonomous reporting • SystemType: define the reporting based on what RAT (e.g. E-UTRAN) • OtherRATReportingSupport: turn on or off the autonomous reporting function • AN can include the control in the SectorParameters message near the boarder cells.

4. Suggestions (3) • Redirect message • If the purpose is not to redirect to other HRPD channel, use new message for the purpose of redirecting to other RAT (e.g. OtherRATRedirect message). • Broadcast type OtherRATRedirect message should be supported • Can include fields other than channel information for group redirect (e.g. redirect a set of UE to E-UTRAN or another RAT type). For example: • All UE in active state, or • All UE with certain QoS profile negotiated, or • All UEs with a particular Apersistence class, or • All UEs has a specific ACCOLC value assigned, or • Other grouping methods • Other potential fields can be included in the OtherRATRedirect message: • SystemType • MinimumRedirectThreshold: This is the redirecting signaling strength threshold (EUTRA) has to be met before redirection can happen • DelayTimer: To make sure the intended ETURA channel has stable signal quality before switching.