1. Architecture and Handoff with S-RNC Fatih Ulupinar, Peerapol Tinnakornsrisuphap, Jun Wang Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization 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 portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. 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. Contributors specifically reserve 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.

2. 2 Potential Architecture with S-RNC Home Agent eBTS S-RNC Access Gateway eBTS IAP Access Gateway eBTS S-RNC eBTS WiFi AP PDIF

3. 3 Pros & Cons of S-RNC Potential benefits of separating S-RNC from eBS –Reliability of Users session Centrally located S-RNC provides higher reliability to user’s session compared to eBTS deployed at the edge. –Provide UATI stability as IAP moves between eBSes. Note, UATI HA can provide UATI stability using an off-the-shelf solution. Separate S-RNC solution does not require a UATI-HA –Centralize paging area management Disadvantages of S-RNC –Additional protocol complexity as new interfaces has to be defined –One more (S-RNC) air interface aware node has to be built

4. 4 Functions of S-RNC Session Anchor (Session Storage Point) –UATI Points to S-RNC Paging and Location Management Idle State Management EAP Authenticator Functions (see EAP Authenticator Placement contribution) –AAA Client Optionally served as IAP when the AT is in idle State: –Buffer Incoming User Data when the AT is in idle state –PMIP Client

5. 5 Related Entities Internet Attachment Point (IAP) – the entity that the AGW points its tunnel for FL traffic to S-RNC is a separate functional entity from AN. However, the AT always maintain a logical route to S-RNC, i.e., S-RNC is also a member of the Active Set S-RNC can either be a stand-alone entity, collocated with AGW or collocated with eBS. This allows flexible deployment options based on operators and vendors’ requirements As a member of the Active Set, S-RNC may become IAP if appropriate –Alternatively, UMB air-interface allows S-RNC to disable data through S- RNC route if S-RNC cannot handle user data

6. 6 S-RNC Interfaces Interface between S-RNC and eBS: –Same as inter-eBS interface –Key is distributed to the eBS Interface between S-RNC and AGW: –No specific 3GPP2 signaling interface is needed between S-RNC and AGW –Same as interface between eBS and AGW –PMIP tunneling can be established when the AT moves to idle

7. 7 Paging Options Allows both the following options: –Option 1: (IAP (Data Anchor) is always separate than S-RNC) IAP receives the data from AG IAP contacts S-RNC for paging S-RNC pages via other APs AT accesses APx APx retrieves data from the IAP and forwards to AT APx starts L3 HO to itself –Option 2: (S-RNC is the IAP when idle) S-RNC receives data from AG S-RNC pages via other APs AT accesses APx APx retrieves data from the S-RNC and forwards to AT APx starts L3 HO to itself If an S-RNC vendor can not handle user data, then it can use option 1

8. 8 Paging (Option1)

9. 9 Paging (Option2)

10. 10 Why Data should be buffered in IAP? - If AGW buffers the data when AT is idle AGW needs to be aware of the status of the AT (active/idle) –Extra signaling messages need to be defined This will be 3GPP2 UMB specific functionality Even PDSN right now is not aware of the status of the AT – PCF was created to ‘shield’ such information from PDSN AGW has two different behaviors depending on the status of the AT – introducing more race conditions, error scenarios to be addressed (e.g., AT is active while AGW still believes AT is idle) and additional delay Air-interface does not only have active and idle state but also has semi-connected state and these may change in the future – change in the air-interface spec should not affect AGW –Excessive additional signaling load will be introduced eBS needs to inform AGW every time an AT changes status from active to idle – this is a very frequent event, for example –To save power, AT may transition to idle state after a short inactivity timer expires – this can be during a short reading time between each web page or Instant Messaging KeepAlive –Every time AT wakes up to register, the AGW will receive idle->active indication and then immediately active->idle indication –Bandwidth between AGW to eBS is likely to be limited and expensive We do not believe this is a scalable solution when the number of AT served by AGW is large The concept is unproven – no other system has chosen this particular design

11. 11 Why Data should be buffered in IAP? - If IAP buffers the data when AT is idle If buffering data at the eBS is a concern, then S-RNC can become IAP when AT becomes idle –Typical amount of data that needs to be buffered when AT is idle is small anyway, e.g., Mobile-Terminated SIP INVITE Allow flexibility for deployment options depending on the physical location of S-RNC while the standard can remain option-free No need for defining extra interfaces –Between AGW and BS for AT status update –Between S-RNC and AGW for paging trigger Compatible with the current PDSN functionalities Avoid extraneous signaling messages as IAP location is more stable than active/idle states

12. 12 Active Set Add (AN2 belongs to same AGW, Interface ID=AGW1 )

13. 13 Active Set Add (AN2 belongs to different AGW, Interface ID=AGW1 )

14. 14 L3 HO w FL Data (Intra-AG HO, no CoA change)

15. 15 L3 HO w RL Data (Intra-AG HO, no CoA change) *Assuming reverse tunneling through IAP

16. 16 L3 HO w RL Data (Intra-AG HO, no CoA change) *Assuming RL data can be directly tunneled from RLSA to AG

17. 17 L3 HO w FL data (Inter-AG HO, CoA change)

18. 18 L3 HO with RL data (CoA change, Inter-AG HO) *Assuming RL data can be directly tunneled from RLSA to AG

19. 19 L3 HO with RL data (CoA change, Inter-AG HO) *Assuming reverse tunneling through IAP

20. 20 S-RNC HO

21. 21 Recommendations No Specific 3GPP2 signaling interface between S-RNC and AGW –Same interface as eBS-AGW interface shall be used Buffer the incoming data in either S-RNC or IAP when the MS is in idle AGW shall be an access agnostic entity