Jun Wang Anand Palanigounder Peerapol Tinnakornsrisuphap George Cherian Chandru Sundarraman Jack Nasielski QUALCOMM Inc. Douglas Knisely Airvana Page 1 Femto Access Control Notice © All rights reserved. The contributors grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner ’ s name any Organizational Partner ’ s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner ’ s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner ’ s standards publication. The contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner ’ s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

Background QUALCOMM submitted Femto Access Control (FAC) related contributions in last PDS CC and June face to face meeting  Refer to X QC Femto Access Control.ppt, and  X QC Femto Access Control.ppt FAC feature was discussed in the joint TSG-A and X (MMD and PDS) 3GPP2 June face- to-face meeting since this feature will impact both TSG-X and TSG-A FAC feature is very critical to the Femto design and specifications  Since most of 3GPP2 femto specifications are close to R&F process, we need a practical and technically solid solution for 3GPP2 femto phase I QUALCOMM took an action item in June meeting to specify the scope of the FAC This slide addresses the following issues:  FAC scope and requirements  Proposes a solution which can be agreed by the group Page 2

Scope of Femto Access Control Applies to both legacy MSs/ATs and new MSs/Ats The new MS means the MS which is aware of FAP Specifies ACL Storage Entity and Enforcement Point and the corresponding interfaces and protocols Specifies procedures for the ACL Storage and Enforcement entities ACL Provisioning Page 3

Proposals Configure FAP Type through FAP-FMS interface  FMS can optionally send ACL to the FAP if the FAP is Restricted or Signaling Association Based on operator’s policy: For 1xCS/Packet or HRPD: FAP can be the enforcement point with FMS to be the storage entity For HRPD: AN-AAA can be both storage entity and enforcement point:  ACL list for a FAP can be stored in AN-AAA  AN-AAA can fail A12 authentication of an AT if the FAP type is restricted association or signaling association and the MS is not within ACL  The existing A12 interface can be used For 1x: FCS can be the enforcement point and the database that hold the ACL subscription (e.g., HSS/AAA/HLR) can be the storage entity or the database can be both storage entity and enforcement point  A new interface between FCS and the database (e.g., HSS/AAA/HLR) is needed  FFS in PDS/MMD Page 4

HRPD/1x Packet Femto Architecture (No Changes) Page 5 Fm interface is used for FAP type configuration and optionally for delivering ACL from the FMS to FAP Reuse A12 interface for HRPD and AN-AAA needs to be updated if AN-AAA is used for FAC storage entity and enforcement point

SIP Based 1x CS Femto Architecture Update Page 6

Procedure for FAP/AN-AAA as an Enforcement Point (1) Page 7 If the type is the open association:  No special procedure for FAP  There is no ACL If the type is the restricted association :  If FAP obtains ACL from the FMS during FAP auto-configuration o Based on policy 1x FAP may reject the RGM (or some air interface signalings) if the MS is not in the ACL or FAP may still send SIP signaling to the FCS o Based on policy, HRPD FAP may reject the HRPD session negotiation if the MS is not in the ACL or FAP may setup HRPD session and perform A12 authentication with AN-AAA  AN-AAA will fail the authentication if the MS is not in ACL  If FAP has not obtained ACL from the FMS during FAP auto- configuration o 1x FAP shall send SIP signaling to the FCS as normal and let FCS perform FAC function o HRPD FAP shall setup HRPD session as normal and perform A12 authentication with AN-AAA

Procedure for FAP/AN-AAA as an Enforcement Point (2) If the type is the signaling association:  FAP processes any signaling messages sent to the FAP  If FAP obtains ACL from the FMS during FAP auto-configuration o 1x FAP accepts the RGM/ORM/PRM (or any air interface signaling): If the MS is not in the ACL, the FAP may redirect the MS to the Macro BS when the MS is establishing the call o HRPD FAP accepts the HRPD session negotiation with the AT If the AT is not in the ACL, the FAP may redirect the AT to the Macro AN based on operator’s policy (e.g., after the AT exceeds a limited number of bytes allowed)  If FAP has not obtained ACL from the FMS during FAP auto-configuration o 1x FAP sends SIP signaling to the FCS as normal and let FCS perform FAC function (i.e., redirection function) o HRPD FAP will get A12 authentication failure indication from AN-AAA during A12 authentication process FAP knows this AT is not in ACL FAP may redirect the AT to the Macro AN based on operator’s policy (e.g., after the AT exceeds a limited number of bytes allowed) Page 8

Procedures for FCS as an Enforcement Point Page 9 FCS is aware of the associated FAP’s types and ACL from Database (e.g., HSS/HLR/AAA) If the associated FAP type is the open association : No special procedure in FCS If the associated type is the restricted association : FCS only allows the MS in ACL to access the system FCS rejects the MS registration (and other SIP signaling such as SIP Invite etc) if the MS is not listed in the ACL If the associated type is the signaling association: FCS allows all the MS to send SIP signaling to the system FCS accepts the MS registration/MS Origination: If the MS is not in the ACL, the FCS may redirect the MS to the Macro BS when the MS is establishing the call

Documentation FAP-FMS interface regarding FAC will be specified in X.S00xx led by Femto Management Object Adhoc FAP enforcement behavior and AN-AAA procedures for A12 authentication will be specified in A.S0024 during R&F and V&V process (no changes are needed to the existing A12 interface) FCS-Database (e.g., AAA/HSS/HLR) interface and procedures will be specified in X.S0059 (FFS on which part) X.S xCS architecture may be updated if TSG-X decide to include FCS-ACL storage database interface in Release 0 Page 10

Recommendations Page 11 Adopt the following proposals as suggested in this contribution:  Configure FAP with FAP types (open, restricted, or signaling association) and optionally send ACL to the FAP if the FAP is Restricted or Signaling Association through FAP-FMS interface.  For 1x/HRPD: FAP can be the EP if ACL exists based on operator's policy  For HRPD, the AN-AAA can be both storage entity and enforcement point for HRPD FAC  For 1x: FCS can be the enforcement point and the database that hold ACL subscriptions (e.g., HSS/AAA/HLR) can be the storage entity for 1x CS FAC or the database can be the both enforcement point and the storage point Add the FAP and FMS procedures regarding FAC function in the corresponding documents (X.P for FMS and A.S0024 for FAP) Add FAP enforcement behavior and AN-AAA procedures for A12 authentication for HRPD FAC function in A.S0024 Add FCS-database (e.g., AAA/HSS/HLR) interface and procedures (FFS in PDS/MMD)