1. All-IP Access Network Issues 1 TSG-A/3GPP2 All IP Access Network Issues -- TSG-A View -- February 17-18 2000

2. All-IP Access Network Issues 2 TSG-A/3GPP2 Assumptions/Issues  TSG-A assumes that an “all IP” network would be required to handle legacy mobiles as well as future “all IP” mobiles.  Call control for these new mobiles would be based on new protocols such as SIP or H323.  Current mobiles use a different type of call processing, there is a need for different handling of these mobiles in the access network. For example there needs to be a function in the network to “route” calls depending on their types.  TSG-A examined two possibilities: routing would be done either inside the IP RAN (in BSC/RNC) or at its edge (e.g., in a PDSN like entity). TSG-A would like a discussion on this topic to progress the all IP work.

3. All-IP Access Network Issues 3 TSG-A/3GPP2 Assumptions/Issues  It is our understanding that current standards for SIP and H.323 do not include appropriate support for mobility. Such mobility is currently supported in the access network protocols with their associated radio interface signaling procedures. We assume that enhancements to these protocols would be required to support mobility.  One possibility that was envisaged would require an external and separate entity, the “mobility manager”.  A new protocol needs to be defined for the interface between the mobility manager and the IP RAN.  Again, since this has implication on other TSGs’ work we would like a discussion on this issue.

4. All-IP Access Network Issues 4 TSG-A/3GPP2 Assumptions/Issues  According to our understanding, it is envisaged that a future wireless IP network would make use of IP Feature Servers to externalize feature handling.  One issue is how these servers would inter-operate with the RAN. One possibility envisaged was that these servers would interact with a “Feature Manager”.  This feature manager would interface with the call processing (CC) and mobility management (MM) entities as well as the IP RAN. We would like to know what other possibilities have been envisaged so far.  More generally, we would like a discussion on what functions could be associated with the above- mentioned servers and feature managers.

5. All-IP Access Network Issues 5 TSG-A/3GPP2 Assumptions/Issues  TSG-A feels that there is a need to develop a clear terminology and to describe the various packet networks involved: -Access IP network – assumed to be a closed, private network. -Core IP network (TSG-A believes that this could be a different network from the Access IP Network). -Backbone IP network(s) used for transport of IP traffic originating or terminating in the Wireless IP Network.

6. All-IP Access Network Issues 6 TSG-A/3GPP2 Assumptions/Issues  One important issue that we have discussed is that transcoding may no longer be done in the Access Network. It may potentially be done outside the serving network. The operators would want to put the transcoding as close as possible to where it is required.  It was agreed that transcoding be done in an external node which is tentatively called PSTN or Media gateway.  Many questions were raised by this assumption: for example, how to signal type of transcoding (to be used in this gateway) across different networks.  TSG-A requests guidance from the all IP ad hoc in order to develop this functionality in the Radio Access Network.

7. All-IP Access Network Issues 7 TSG-A/3GPP2 Assumptions/Issues  TSG-A agreed to keep the Frame Selector function in the IP BSC/RNC. This raises the question of how the selector interfaces with the transcoder. This is not done in the current Access Network standards. TSG- A intends to define this interface, so called IP A12. IP A12 is defined as the RAN bearer interface for any traffic destined for a media gateway to a non-IP network or application.  TSG-A will seek to re-use as much as possible existing or future protocols. For example, there is a benefit in using the same protocol structure for all bearer interfaces such as the IP A12, A8 and A10 interfaces. Similarly, control and signaling interfaces would benefit from sharing the same structure and protocol stack.

8. All-IP Access Network Issues 8 TSG-A/3GPP2 Assumptions/Issues  A question was raised on how to maintain synchronization within the IP Radio Access network. Synchronization is a very important function in the RAN today and is essential for example to ensure soft handoff support.  TSG-A believes that there is significant benefit to the industry to harmonize Wireless IP architectures for various third generation (3G) standards currently being defined.  However, convergence with 3GPP’s architecture presents significant challenges due to the fact that 3GPP currently uses a GPRS based architecture and an ATM RAN versus an IP/Mobile IP based architecture used in the 3GPP2 IOS V4.

9. All-IP Access Network Issues 9 TSG-A/3GPP2 Assumptions/Issues  Therefore, TSG-A does not recommend that 3GPP2 and 3GPP Access Network architecture be merged.  Correspondence between 3GPPs is strongly recommended given the early stages of development for this architecture in both SDOs.  Ideally the IP RAN architecture could be defined to be access (radio technology) independent.

10. All-IP Access Network Issues 10 TSG-A/3GPP2 Assumptions/Issues  TSG-A discussed whether supporting soft handoff between all IP Radio Access networks and 3G legacy networks was a requirement. Guidance from the all IP ad hoc on this topic is requested.  TSG-A assumes that hard handoff between all IP Radio Access networks and 3G legacy networks is required.  TSG-A assumes that calls would be anchored at the BSC/RNC for the purpose of soft handoffs while in active mode.  This does not mean that the same BSC would act as the anchor for the whole duration of a packet data call (i.e. dormant handoffs are always possible).