AIPN Scenarios

AIPN or All-IP Network is being introduced part of 3GPP Release 7. TS 22.978 shows some scenarios where AIPN will play a big part

USE CASE 1 (see left in the daigram): Bob has his own Personal Area Network (PAN). While at home, this network is composed with the Home Area Network using WLAN, which in turn connects externally with a local hotspot service, which in turn connects to a cellular network. Bob's PAN, Bob’s Home-WLAN, the local hotspot service and the AIPN cellular access system are under different administrative domains. Still, if Bob moves outside coverage of his Home-WLAN, his PAN will communicate with the outside world via the local hotspot service. If he moves outside coverage from the hotspot service, his PAN will communicate with the outside world via the AIPN cellular access system.

USE CASE 2: The user is driving a car. While being under good radio coverage, he starts an IMS session with several media. The car goes through a tunnel where there is no radio coverage, and comes out of the tunnel into good radio coverage a minute later. Connections using disruption resilient transport protocols are automatically re-established and these protocols restore the communication to the point they were before the interruption.

USE CASE 3: Alice has a mobile device and Bob has a fixed one. Both devices have equal audio but different video capabilities in terms of screen size, number of colors and video codecs supported. Alice establishes a multimedia connection with audio and video components to Bob. The terminal capabilities are discovered and it is realized that Bob's terminal has better video capabilities than Alice. The terminal informs the network that it is unable to support new the new video codec and the AIPN then introduces a video transcoder in the path of the video media to adapt the video signal (stream, codec, format, etc) to the video capabilities and bit rates available on each side of the transcoder.

Enhanced Services should be possible with AIPN:

• Support for advanced application services
• Support for group communication services, e.g. voice group call, instant group messaging, and multicast delivery. In some cases, a group may include a large number of participants.
• Support for integrated services, e.g. a service including a mixture of services among SMS/MMS/Instant Message, or a service including voice call/video call/voice mail.
• Provision of seamless services (e.g. transparent to access systems, adaptable to terminal capabilities, etc) Users should be able to move transparently and seamlessly between access systems and to move communication sessions between terminals.
• Support ubiquitous services (e.g. associations with huge number of sensors, RF tags, etc.) ... see right side of diagram above.
• Improve disruption-prone situations when network connectivity is intermittent.

Disruption-free network connectivity may not be cost effective, or even feasible, in all cases (e.g. cell planning for full radio coverage for all services, disruption-free inter-access system handovers, disruption-free IP connectivity in all network links). An AIPN should consider solutions for making services as resilient to temporary lack of connectivity as possible.

Continuous Packet Connectivity (CPC)

Packet-oriented features like HSDPA and HSUPA (HSPA) in UMTS systems provide high data rates forboth downlink and uplink. This will promote the subscribers’ desire for continuous connectivity, where theuser stays connected over a long time span with only occasional active periods of data transmission, andavoiding frequent connection termination and re-establishment with its inherent overhead and delay. Thisis the perceived mode to which a subscriber is accustomed in fixed broadband networks (e.g., DSL) andmay make a significant difference to the user experience.

The Fractional-DPCH feature was introduced in Rel-6 to support a high number of HSDPA users in thecode limited downlink, where effectively a user in the active state, not being transmitted with any data, isconsuming only a very small portion of the downlink capacity.

In the uplink, the limiting factor for supporting a similarly high number of users is the noise rise. For sucha high number of users in the cell it can be assumed that many users are not transmitting any user datafor some time (e.g., for reading during web browsing or in between packets for periodic packettransmission such as VoIP). The corresponding overhead in the noise rise caused by maintained controlchannels will limit the number of users that can be efficiently supported.

Since completely releasing the dedicated connection during periods of traffic inactivity would cause considerable delays for reestablishing data transmission and a correspondingly worse user perception,the Continuous Connectivity for Packet Data Users intends to reduce the impact of control channels onuplink noise rise while maintaining the connections and allowing a much faster reactivation for temporarily inactive users. This is intended to significantly increase the number of packet data users (i.e. HSPA users) in the UMTS FDD system that can stay in the active state (Cell_DCH) over a long time period,without degrading cell throughput. The objective aims also at improving the achievable UL capacity forVoIP users with its inherent periodic transmission through reducing the overhead of the control channels.

Delay optimization for procedures applicable to PS and CS Connections

In Rel-99, UMTS introduced a dedicated channel (DCH) that can be used for CS and PS connectionswhen UE is in CELL_DCH state. In addition to CELL_DCH state, Rel-99 introduced CELL_FACH statewhere signaling and data transmission is possible on common channels (RACH and FACH) andCELL_PCH and URA_PCH states, where the transmission of signaling or user data is not possible butenables UE power savings during inactivity periods maintaining the RRC connection between UE andUTRAN and signaling connection between UE and PS CN. The introduction of the CELL_PCH andURA_PCH states, the need of releasing the RRC connection and moving the UE to Idle mode for PSconnections was removed and thus the Rel-99 UTRAN can provide long living Iu-connection PS services.

On the other hand, when UE is moved to CELL_PCH or URA_PCH state, the start of data transmissionagain after inactivity suffers inherent state transition delay before the data transmission can continue inCELL_DCH state. As new packet-oriented features like HSDPA and HSUPA in Rel-5 and Rel-6 UMTSsystems respectively provide higher data rates for both downlink and uplink in CELL_DCH state, the statetransition delay has been considered to be significant and negatively influencing the end user experience.

In addition to RRC state transition delay, the radio bearer setup delay to activate new PS and CS serviceshas been seen as problematic in UMTS, due to signaling delays on CELL_FACH state where only lowdata rates are available via RACH and FACH, and due to activation time used to synchronize thereconfiguration of the physical and transport channel in CELL_DCH state.

To secure future competitiveness of UMTS and enhance the end user experience even further, the delayoptimization for procedures applicable to PS and CS connections work is targeted to reduce both setuptimes of new PS and CS services and state transition delays to, but still enable, excellent UE powersaving provided by CELL_PCH and URA_PCH states.

During the 3GPP Rel-6 time frame, the work was focused on solutions that can be introduced in a fastmanner on top of existing specifications with limited effects to the existing implementations. In addition,the solutions which allow the Rel-6 features to be used in the most efficient manner were considered.The agreed modifications can be summarized as: introduction of enhanced support of defaultconfigurations, reduced effects of the activation time, and utilization of HSPA for signaling. Thus, fromRel-6 onwards, the signaling radio bearers (SRBs) can be mapped on HSDPA and HSUPA immediatelyin RRC connection setup and default configurations can be used in radio bearer setup message and RRCconnection setup message in a more flexible manner.

The utilization of default configuration and mapping of the SRBs on HSDPA and HSUPA will reducemessage sizes, activation times, and introduce faster transmission channels for the signaling procedures,thereby providing significant enhancement to setup times of PS and CS services compared to Rel-99performance.

In the 3GPP Rel-7 time frame, the work will study methods of improving the performance even further,especially in the area of state transition delays. As the work for Rel-7 is less limited in scope of possiblesolutions, significant improvements to both RRC state transition delays and service setups times are expected.

3GPP TR 25.903: Continuous connectivity for packet data users (Release 7)

3G Americas: Mobile Broadband: The Global Evolution of UMTS/HSPA3GPP Release 7 and Beyond

Housam's Technology blog on CPC

Voice call continuity (VCC)

Voice call continuity requires maintaining a voice call when a mobile terminal moves from one cell to another for second generation Global System for Mobile Communications (GSM) digital cellular communications systems. Operational for many years, this technique enables a conversation to continue when the Circuit-Switched (CS) call reroutes to use a new basestation as the mobile moves from one coverage area to another. The parties will perceive no break whatsoever.

Today, the scenario is rather more complicated, with calls being handed over not only from 2G to 2G cells and from 3G to 3G cells, but also between 2G GSM and 3G Universal Mobile Telecommunications System (UMTS) cells. This is relatively easy from an administrative point of view, given that generally the same cellular network is involved throughout.

Earlier work carried out within the 3rd Generation Partnership Project (3GPP) envisaged telephony using packet-switched connections – Voice over Internet Protocol (VoIP) – using either the 3GPP-defined IP Multimedia Subsystem (IMS) on the 3G Universal Terrestrial Access Network (UTRAN), or Wireless Local Area Network (WLAN) radio access technology based on IEEE 802.11, and other standards. This was covered by the WLAN interworking work items.

However, until now, handover between CS and IMS (packet-switched) calls was not addressed. 3GPP is now investigating the problem of handing over a voice (or potentially video or other multimedia conversational service) call between the cellular network and a WLAN, possibly operated by a completely different service provider. Again, for conversational service, the hand-over has to be seamless, with no break in service perceived by either party to the call. Until recently, such handover had only been considered for services that are not real-time, such as file-transfer, where short breaks during the handover process are acceptable and probably go unnoticed by the user.

The approach taken by 3GPP is to have the WLAN operator use the information registered by the home operator for the mobile terminal subscriber in this sequence:

1. Validate the eligibility of the handover to happen at all
2. Manage charging for the call that is effectively transferred from one network operator to another

It is generally, though not necessarily, the case that WLAN hotspots are also well covered by cellular service. Thus, such handover may take place when cellular coverage is reduced to an unacceptable level, yet an adequate WLAN hotspot service is available. The handover is more likely to occur when spare bandwidth exists on the WLAN but where excess demand for cellular channels exists.

The goal is to maintain the conversational service call, thus optimizing the service to the users, which in turn will maximize the revenue accruing to the operator(s). 3GPP embarked on the technical activity required to enable this service by approving a work item on Voice Call Continuity (VCC) in the June 2005 meeting of its Technical Specification Group System Aspects and Architecture (TSG SA). In order to be accepted onto the 3GPP work plan, any work item needs to have the support of at least four supporting member companies, and no sustained opposition. The VCC work item has no fewer than 16 supporters, and its progress
can be tracked on the 3GPP website, www.3gpp.org. It is intended that this work be achieved in the Release 7 time frame.



3GPP TR 23.806: Voice Call Continuity between CS and IMS Study (Release 7)
3GPP TS 23.206: Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2 (Release 7)
3GPP TS 24.206: Voice Call Continuity between the Circuit-Switched (CS) domain and the IP Multimedia Core Network (CN) (IMS) subsystem; Stage 3 (Release 7)
3GPP TS 24.216: Communication Continuity Management Object (MO) (Release 7)

http://www.compactpci-systems.com/columns/spec_corner/pdfs/2006,04.pdf
http://www.huawei.com/publications/viewRelated.do?id=1146&cid=1802
http://news.tmcnet.com/news/it/2006/06/02/1667856.htm
http://www.tmcnet.com/usubmit/-an-introduction-voice-call-continuity-vcc-/2007/05/02/2577864.htm
http://www.tmcnet.com/wifirevolution/articles/5861-voice-call-continuity-solution-dual-mode-wi-ficdma.htm

MBMS Enhancements in Release 7

MBMS will be undergoing enhancements in Release 7 and this work item is seperate from E-MBMS or Enhanced MBMS which is part of 3GPP Long Term Evolution (LTE).

MBMS is being enhanced in Release 7 and IMS will be able to use MBMS transport. The advantage of this approach is:

• MBMS reception is possible over IP accesses (e.g. I-WLAN)


• Higher MBMS bit rate services possible (e.g. HDTV)


• Support for adaptation of MBMS to the QoS resources provided by the access network(s)


• MBMS services will be available regardless of access technologies and other services will be able to usse MBMS transport

This MBMS Enhancement is still under development and the following is being investigated:

• Radio Interface Physical Layer: Introduction of new transmission schemes and advanced multi-antenna technologies


• Layer 2 and 3: Signalling optimisations


• UTRAN Architecture: Identify the most optimum architecture and functional splits between RAN network nodes
  

3GPP website lists some of the aims and objectives of these MBMS enhancements but theey do not look correct. They are copied from the LTE requirements documents. I will be revisiting this topic when more information is available