Making of a Gentleman - An autobiography

Before I start writing a small story, I must foretell that its not jactitation of myself. Although for now, title might strongly suggest so.

It all started 7 years back when i joined an IT company, which was one of the best brands in India. It was certainly not less than a dream-come-true. Although some people having served so long (or more, or little less), have reasons to differ; many others still believe it is.

During college days, 'being a gentleman' was not even on any one's mind. Infact, it used to be just the opposite. With the kind of education system India has, every single attempt is made that students excel in studies, books and core subjects. There is hardly any attempt to work on their behaviour. There is no need for me elaborate on what goes in college as any mention would be far too less. My experiences would only serve as a subset of all that is worth mentioning. Instead I will go ahead to write more about the 'transformation'.

Indian IT has earned itself a name all over the world and has made Indians proud. And believe me, it has. Fortunately I had opportunity to talk to people from Finland, UAE, America, Sudan and China. And thanks to IT industry for the recognition Indians enjoy today.

But among all these achievements, one achievement is not even seldom mentioned. To say it in short, making the people feel better within India. Making me feel that I am a better citizen, a better individual, a gentleman.

Of all the jargon i have learnt over the years in my organization, certain learnings have added maximum value to me. From things as small as holding the door for person coming next to keeping queues (which certainly is not a small thing for people staying in Delhi, NCR), all do matter. Respecting your colleagues and especially women colleagues is probably most important. Of the many other things learnt, talking respectfully to juniors is indeed foremost. Acknowledging and honouring other religions couldn't be better learnt. The way one of my Muslim friends, joined everyone else for Diwali decorations (Ramayana theme) made me feel ashamed of myself. I was appreciating him for his efforts but more because he belonged to a different religion. Such people become an inspiration and hence the culture of an organization. His enthusiasm or for that matter anyone else's, makes religion look small in front of the spirit of people, who are working together for a same cause and for a same organization.

Every time, my company organizes a blood camp and every time i have availed this chance to contribute something to my society, I come home a winner. Each time, it distributes books or donates computers to underprivileged children, I am a proud employee. I am happy that organization makes contributions for the welfare of family of deceased fellow-employees and more so because each time I am a part of such an effort.

Development of such traits, comes so easy while working in Indian IT companies that it is almost always ignored. People value it only outside the office premises. And things could not be better when cost of these learnings are not included in CTC (Cost to Company).

Of few companies I was lucky to interface with are Microland and Aricent. But I am sure that these traits are essence of whole of IT industry. Thanks to these organizations for inculcating these values in me and making me what I am today.

Quality of Service in GPRS (General Packet Radio Service) RAN

Author: Atul Gargi (gargia@gmail.com)

Introduction

Quality of Service (QOS) is assuring the user a particular experience, in terms of data rate and end-quality. Network achieves this by managing the available bandwidth and taking care of adverse factors by prioritizing, delaying and redundancy (retransmissions). The objective of QOS is not to provide additional bandwidth, but instead manage the available bandwidth.

There are different QOS requirements for different types of data flows. For example, FTP can be served by a best effort service (no delay requirements) while Push To Talk Over Cellular (POC) call has certain real-time constraints. While data of an application is being handled at normal priority, GPRS signaling messages need to be sent on higher priority. Such requirements are met by different kinds of traffic profiles: streaming, interactive and best-effort.

The purpose of this white paper is to present the procedures available in GPRS to support QOS and run streaming applications. The scope of this paper is to explain the relevance of PDP and PFC during QOS connection establishment and data transfer. It also details how the application protocols use QOS support provided by GPRS.

Abbreviations

ABM	Asynchronous Balanced Mode (LLC acknowledged mode)
ADM	Asynchronous Disconnected Mode (LLC un-acknowledged mode)
AVP	Audio Video Protocol
BSC	Base Station Controller
BSSGP	Base Station System GPRS Protocol
BTS	Base Station Transceiver
BVC	BSSGP Virtual Connection
EGPRS	Enhanced GPRS
GGSN	Gateway GPRS Support Node
GMM	GPRS Mobility Management layer
GTP	GPRS Tunneling Protocol
IP	Internet Protocol
LLC	Logical Link Control
MAC	Medium Access Control layer
MS	Mobile Station
NCCR	Network Controlled Cell Change
NSAPI	Network Service Access Point Identifier
PDP	Packet Data Protocol (e.g. IP)
PDU	Packet Data Unit
PFI	Packet Flow Identifier
RAN	Radio Access Network
RLC	Radio Link Control layer
SAPI	Service Access Point Identifier
SGSN	Serving GPRS Support Node, in PS domain
SM	Session Management
SNDCP	Sub Network Dependent Convergence Protocol
TCP	Transmission Control Protocol
TDMA	Time Division Multiple Access
TFT	Traffic Flow Template, describes how packets belonging to a given PDP context can be identified
UDP	User Datagram Protocol
URI	Universal Resource Identifiers

Definitions

PFC (Packet Flow Context):

To support multiple QOS profiles for different types of data flows while a TBF is ongoing, PFCs are created. PFC promises a QOS in PCU across both Gb and Um interfaces. It is identified uniquely within a mobile context by a PFI (Packet Flow Identifier).

PCU (Packet Control Unit):

It is a unit in BSC that provides GPRS services and controls Packet Data Channels (PDCH). It interfaces with BTS (ABIS interface), BSC and SGSN (Gb interface). It performs RLC/MAC functionality and radio resource management in BSC for packet data services.

PDP Context (Packet Data Protocol Context):

It is a GPRS session between mobile subscriber and core network (SGSN and GGSN). PDP context relates to IP address and GTP-Tunnel Identifier activation. When specific QOS requirements are to be promised, PDP context activation also involves PCU (Packet Control Unit) to make reservations on Um (Air) interface.

TBF (Temporary Block Flow):

TBF is a connection between PCU and MS, retained only for the duration of data transfer. An MS in data transfer mode is uniquely identified by a TFI (Temporary Flow Identifier). TBF establishment includes assignment of radio frequency and timeslots to MS.

Traffic Classes

Establishing priority and organizing data flows as per their delay sensitivities is achieved through traffic classes. The various traffic classes (in decreasing order of priority) are:

1. Conversational

• Preserve time relation (variation) between information entities of the stream

• Conversational pattern (stringent and low delay)

2. Streaming

• Preserve time relation (variation) between information entities of the stream

3. Interactive

• Request response pattern

• Preserve payload content

4. Best-Effort

• The destination is not expecting the data within a certain time

• Preserve payload content

Conversational class is meant for traffic, which is very delay sensitive while Best-Effort class is the most delay insensitive traffic class. The main divider between Conversational and Streaming is how delay sensitive the traffic is. Conversational real-time services, like video telephony, are the most delay sensitive applications and those data streams should be carried in Conversational class. Interactive class and Best-Effort are mainly to be used by traditional Internet applications like WWW, Email, Telnet, FTP and News. The main difference between Interactive and Best-Effort class is that Interactive class is mainly used by interactive applications, e.g. interactive Email or interactive Web browsing, while Best-Effort class is meant for background traffic, e.g. background download of Emails or background file downloading. Traffic in the Interactive class has higher priority in scheduling than Best-Effort class traffic, so background applications use transmission resources only when interactive applications do not need them.

Streaming

‘Streaming’ traffic class allows the user to start receiving and “experiencing” in real time. Such a service is needed essentially where contents are not to be saved. There are numerous applications like voice chat, real-time video, news etc.

The challenge posed by streaming application is guaranteeing a bitrate. As long as bandwidth is sufficient (more than bitrate requirement) and quality of the transmission medium is good, supporting streaming is not really a challenge. But as multiple MS are multiplexed, the available bandwidth is shared. This imposes a requirement on GPRS network to prioritize streaming over best-effort traffic class such that while streaming application runs with required bitrate; best-effort does not starve either.

Figure-1 below presents a “layered view”, of the entities in GPRS network that are involved in signaling and data path to provide streaming service.

Figure 1: Layered view- Streaming service in GPRS

QOS Implementation

One of the QOS decisions is to choose between Acknowledged and Un-Acknowledged modes at three levels i.e., TCP/UDP (Transport Layer), LLC and RLC/MAC. This section explains QOS at these three levels.

1. Application layer protocols

2. PDP (QOS associated with SAPI/NSAPI)

3. PFC

Figure 2: QOS Implementation in GPRS

1. Application layer protocols: There are innumerous application protocols and all with different QOS requirements. This layer does not understand if it is using GPRS or any other lower layer protocol. As the highest layer in protocol sack, it is to be provided service as per its requirement. The options at transport layer are like TCP or UDP. Below the IP layer, there are procedures defined in GPRS to support different QOS.

2. PDP (QOS associated with SAPI/NSAPI): As there is a requirement to send an IP packet, SM layer in mobile phone triggers PDP activation procedure. The objective of PDP activation is to fetch a PDP address and QOS. In case PDP request does not specify the QOS, it is fetched from HLR by SGSN and sent back in PDP Accept message. During PDP activation, SM layer informs SNDCP about the NSAPI, SAPI, negotiated QOS and radio priority level to be used at RLC/MAC. SM and GMM layer messages always use LLC-UNACK mode on SAPI 1.

There are four SAPIs supported by LLC layer (on interface with SNDCP) corresponding to four delay classes. These are 3,5,9 and 11. However, there is no relationship between a SAPI and a delay class. Any SAPI can be negotiated for any QOS profile. LLC can operate in ABM or ADM modes. In Release 97, reliability class parameter determines this.

Reliability Class (R97 parameter)	GTP	LLC	RLC	Protected Data
1	-	-	-	-
2	U	A	A	Y
3	U	U	A	Y
4	U	U	U	Y
5	U	U	U	N

U: Un-Acknowledged Mode

A: Acknowledged Mode

Y: Yes

N: No

In release 99, SDU error ratio determines the ACK/UNACK mode for PFC. It indicates the fraction of SDUs lost or detected as erroneous.

SNDCP user keeps the connection mapping of NSAPI and PDP address. Having established the LLC-ACK mode, an SN-DATA-PDU is sent as LL-DATA-REQ to LLC. SN-UNITDATA-REQ is sent as LL-UNITDATA-REQ.

Secondary PDP is activated when a different QOS is required for same PDP address (assigned during Primary PDP activation) and APN (Access Point Name). For example, a streaming connection made over GPRS needs Primary PDP context for RTSP and a Secondary PDP for RTP/RTCP. A TFT (Traffic Flow Template) is associated with each Secondary PDP, transparently sent to GGSN via SGSN. TFT enables packet classification and policing for the downlink data.

Figure 3: Data flow through protocol layers

3. PFC: Packet Flow Contexts are made to service a data flow at a particular QOS in PCU and SGSN. LLC data is transferred between MS and SGSN with an association with PFI. Whenever DL PDU is to be transferred from SGSN, PFI is included in BSSGP_UNITDATA_REQ. In case of sending UL LLC PDU, MS establishes UL TBF for a specific PFI by including the PFI in Channel Request Description in Packet Downlink ACK/NACK message.

Packet Flow Context

PFC in PCU

PCU implements three primary PFC operations:

• Admission Control: Ensures that a new PFC is admitted only if

  • Its QOS requirements can be met within available capacity

  • It does not impact already admitted PFCs such that they starve

• Scheduling

• Delivers prioritization

• Ensures guaranteed bitrate

• Quality Control

  • Takes pre-emptive action under adverse conditions to save the QOS requirements of a PFC. For example:

• Reallocate MS to different timeslots

• Reallocate MS to different cell (NCCR)

• Modification of PFC-QOS to save the data flow e.g. PFC downgrade

PFC in SGSN

SGSN maintains the context of each PFC for every MS. It primarily performs the following two functions:

• Admission Control: Ensures that a new PFC is admitted only if this load can be accommodated in RAN.

• Flow Control: SGSN acts as a buffer to store and release data for each PFC in a BVC in a controlled manner. This is needed because of the limitation of buffering capacity in PCU.

Figure 4: Flow Control in SGSN

At the SGSN, different rules are applied while queuing and de-queuing PDUs for different kinds of PFCs. For example, PDUs belonging to conversational or streaming class PFCs are dropped immediately (to avoid delays) if there is congestion in PFC queues while for Best-Effort traffic class, they remain queued. Signaling PDUs are never dropped.

During MS flow control, comparing within Background and different Interactive PFCs, Weighted Fair Buffer Allocation algorithm is applied. While choosing PFC for which PDU is to be sent to BSS (De-Queuing), Weighted Fair Queuing is applied. There is a weight (priority) associated with each type of PFC and accordingly LLC-PDUs of PFCs are delivered to PCU. Figure-5 describes the Flow control algorithm.

SGSN maintains the rate of flow of LLC PDUs for each PFC such that neither buffering in PCU overflows, nor it is below the current transmission capacity of PFC. To perform this functionality, SGSN estimates if the new LLC PDU can be accommodated in PCU buffers as per algorithm given below.

Figure 5: Flow control algorithm

- Bmax Bucket Size. Set by the BSS for each cell and each mobile station and optionally for each PFC of an MS. Bmax shall be large enough to accommodate at least one LLC-PDU

- R leak rate (Derived from buffering capacity and transmission rate in PCU)

- B bucket counter

- B* predicted value of the bucket counter

- L(p) length of LLC-PDU

- Tp the time that the last LLC-PDU p was transferred

- Tc arrival time of LLC-PDU

PCU informs SGSN periodically about the current leak rate for each PFC (served as R in algorithm above). Leak rate in PCU depends on:

• Coding scheme being used by MS

• Number of Timeslots and slaves used in data transfer

• Radio conditions (error rate and re-transmissions on Um interface)

• Multiplexing in packet data channels (bandwidth is shared among multiple MS)

• QOS parameters of PFC such as priority and guaranteed/maximum bitrate.

Appendix

The solution mentioned in this section is not the only way possible to run streaming application in GPRS network; instead it serves as examples.

Example:

	Transport Protocol	NSAPI	SAPI	PFC
RTSP	TCP	5	3	8
RTP	UDP	6	3	9
RTCP	UDP	6	3	9

Abbreviations:

SR: Sender’s Report

RR: Receiver’s Report

RTCP Messages:

SDES: Source Description

SSRC: Synchronization Source

APP: Application-specific functions

BYE: Indicates end of participation

TCP port number distinguishes RTP and RTCP packets. RTCP uses next higher odd port number than assigned RTP (uses even port number).

Streaming Connection establishment

This section explores in detail the steps involved when a mobile station intends to make a real-time connection. The example explained is that of downloading video on Nokia 6230i phone in real-time.

Mobile station is attached to the network. It intends to open a real-time connection with a Streaming server connected to GPRS network over IP. RTSP client in MS intends to make a connection and triggers PDP activation procedure to obtain an IP address from GGSN.

PDP Request message contains the QOS profile requested by MS (which can be subscribed). This request is received by SGSN and is sent further to GGSN over GTP (GPRS Tunneling Protocol). GGSN allocates an IP address from free pool of addresses after admitting the requested QOS. After receiving ACK from GGSN, SGSN requests the PCU to approve the requested QOS (or one fetched from HLR if MS had sent subscribed). The request is made in CREATE_BSS_PFC message. Such a PFC is called a Non-Predefined PFC. If PCU can support the requested QOS, it acknowledges same to SGSN. Since, non-predefined PFIs start from 8, it is usually assigned PFC that is created whenever first PDP is activated. SGSN sends an ACK to MS, indicating the assigned QOS profile and IP address. The procedure is shown in Figure-6.

RTSP protocol is ready to send its first packet (DESCRIBE) over TCP and activated PDP/PFC. As Streaming server receives DESCRIBE, it responds back with RTSP/1.0 200 OK. The messages are transferred on PFI 8 in PCU. Please refer Figure-7.

Figure 6: PDP Activation procedure

Figure 7: Streaming Connection establishment

Streaming data transfer

The streaming PFC is served by PCU with a guaranteed scheduling to support the negotiated bitrate. Adequate buffering is maintained in PCU and SGSN so as to provide required service. Quality control takes pre-emptive actions whenever quality of transmission medium deteriorates.

The data transfer includes transfer of PDUs of multiple PFCs. During ongoing transfer, there are cases where QOS needs to be renegotiated/changed. E.g.

• Quality of air interface is bad and streaming service can no longer be supported

• MS does cell change but required bandwidth is not available in new cell

In such cases, PCU initiates PFC modification procedure and sends the request to SGSN with a new proposed QOS profile. SGSN sends it to MS in PDP Modify Request message. It can either be acknowledged or rejected by MS. If MS does acknowledge it, on receiving the PDP Modify Accept, SGSN updates the new PFC profile in PCU.

Figure 8: PFC/PDP Modification procedure

Figure 9: Streaming data transfer

Streaming connection termination

Terminating a connection involves deletion at MS, PCU and SGSN. PDP Deactivation procedure is defined between MS and SGSN. As PDP Deactivation request is received by SGSN (from MS), it sends PFC-DELETE message to PCU. PCU deletes the PFC and sends an acknowledgement back to SGSN. SGSN sends PDP Deactivate Accept to MS to complete the procedure.

TEARDOWN frees resources associated with the stream and stops the stream delivery for the given URI. The RTSP session ceases to exist on server. The message identifies the RTSP session by a session-id, allocated during SETUP procedure.

Figure 10: PDP Context Deactivation

Figure 11: Streaming connection termination

Conclusion

Implementing QOS solution has certain challenges in wireless domain. This is due to the hostile nature of air-interface. It is an adaptation of the existing protocol to support services like video-conferencing. QOS solution builds up on GPRS enhancements like EGPRS, extended UL TBF, delayed TBF release, link adaptation, NCCR, Packet TBF Release procedures etc. The procedures are made available to make a service-aware network.

There is a cost associated with more QOS conscious services. To assure predictable delays, resource reservations are needed in different network nodes. This can also decrease the overall system throughput. Therefore, the ratio of streaming users to best-effort users in the system needs to be controlled.

To conclude, the end-customer (mobile user) is the beneficiary of a sensitive QOS solution.