Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Avoid Paging of Mobile Terminals during Real-time Communication in IP Based Mobile Networks (GPRS)

IP.com Disclosure Number: IPCOM000130585D
Original Publication Date: 2005-Nov-25
Included in the Prior Art Database: 2005-Nov-25
Document File: 4 page(s) / 128K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

A mobile station (MS) communicating with the General Packet Radio Service Core Network (GPRS CN) over GPRS Packet Radio Access Network (GERAN) has different possible mobility states. These mobility states and possible state transitions are depicted in Figure 1 for the Gb interface. The Gb interface is a GPRS interface which is located between the Serving GPRS Support Node (SGSN) and the Base Station System (BSS). After the MS has been attached to GPRS, the mobility management (MM) state of a MS changes between READY and STANDBY. In the READY state the MS may send and receive Internet Protocol (IP) packets whereas in the STANDBY state no reception or transmission of data packets is possible. Switching from STANDBY to READY can only be done if the mobile station sends IP packets in uplink (UL). The STANDBY state is not changed by data traffic from the SGSN towards the mobile phone. The SGSN has to send a paging request to the MS via the GPRS signaling-paging-channel and receive a paging response UL from the MS. Thereafter IP packets may be transmitted downlink (DL) over the data channel. This delay may take up to several seconds and leads to the following problem: - the first phonemes of a subscriber's speech get lost. Moreover the STANDBY state is entered from the READY state if the READY Timer (T1) expires after the last IP package has been sent by the MS in UL direction, i.e. from the subscriber. Since the transmission gets interrupted upon expiry of the READY Timer by the paging procedure, another problem occurs:

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 4

S

Avoid Paging of Mobile Terminals during Real-time Communication in IP Based Mobile Networks (GPRS)

Idea: Dr. Andras Balazs, DE-Munich; Johann Bauer, AT-Vienna

A mobile station (MS) communicating with the General Packet Radio Service Core Network (GPRS CN) over GPRS Packet Radio Access Network (GERAN) has different possible mobility states. These mobility states and possible state transitions are depicted in Figure 1 for the Gb interface. The Gb interface is a GPRS interface which is located between the Serving GPRS Support Node (SGSN) and the Base Station System (BSS). After the MS has been attached to GPRS, the mobility management (MM) state of a MS changes between READY and STANDBY. In the READY state the MS may send and receive Internet Protocol (IP) packets whereas in the STANDBY state no reception or transmission of data packets is possible. Switching from STANDBY to READY can only be done if the mobile station sends IP packets in uplink (UL).

The STANDBY state is not changed by data traffic from the SGSN towards the mobile phone. The SGSN has to send a paging request to the MS via the GPRS signaling-paging-channel and receive a paging response UL from the MS. Thereafter IP packets may be transmitted downlink (DL) over the data channel. This delay may take up to several seconds and leads to the following problem:

- the first phonemes of a subscriber's speech get lost.

Moreover the STANDBY state is entered from the READY state if the READY Timer (T1) expires after the last IP package has been sent by the MS in UL direction, i.e. from the subscriber. Since the transmission gets interrupted upon expiry of the READY Timer by the paging procedure, another problem occurs:

- an intermediate piece of the subscriber's speech will get lost if paging occurs.

Operators expect sub-second delays for voice media but these problems cannot be solved by choosing large jitter buffers. The problems impact both real time message flows (Push-to-talk over Cellular, i.e. PoC) and time critical flows (peer-to-peer relationships, i.e. sessions).

At present, if a MS supports Real-time Control Protocol (RTCP), Receiver Reports (RRs) are used between MSs to indicate the number of Real-time Transport Protocol (RTP) packets received, lost, etc. This is defined by the Internet Engineering Task Force (IETF) in "IETF RFC 3550, RTP: A Transport Protocol for Real-time Applications, July 2003". RFC 3550 provides recommendations for the maximum bandwidth that RTCP messages may consume in order to limit the overall bandwidth consumption. The maximum bandwidth usage is taken to calculate a time interval for sending RTCP RR messages.

However, this method leads to frequent RTCP RR responses and therefore consumes too much radio capacity. Instead, periodic transmission of RTCP RR compound packets during RTP Media packet transfer is used as a so called "heart beat" indication from the listening PoC Clients to the PoC server. But still either one or both of the "speec...