5 Bearer Services

22.1053GPPRelease 17Services and service capabilitiesTS

5.1 Definition of bearer services

Bearer services provide the capability for information transfer between access points and involve only low layer functions. These functions are sometimes referred as low layer capabilities (in reference to OSI layers). The user may choose any set of high layer protocols for his communication and the PLMN does not ascertain compatibility at these layers between users.

In the general case a communication link between access points provides a general service for information transport. The communication link may span over different networks such as Internet, Intranets, LANs and ATM based transit networks, having network specific means for bearer control. Each network contributes to the end-to-end QoS perceived by the end-user.

PS and CS domains provide a specific set of bearer capabilities. The Circuit bearer services are described in 22.002 [2]. The packet services (GPRS) is described in 3GPP TS 22.060 [7]. Following chapters describe the overall requirements for both the CS and PS domain bearers and also for the bearers used by teleservices.

5.2 Description of bearer services

Bearer services are characterised by a set of end-to-end characteristics with requirements on QoS. The characteristics and requirements shall cover major network scenarios, i.e. the cases when the terminating network is PSTN, ISDN, IP networks/LANs, X.25 and a PLMN.

Quality of Service is the quality of a requested service (Teleservice or Bearer Service or any other service, e.g. customer care) as perceived by the customer (ITU-T Recommendation E.800 [18]). QoS is always meant end-to-end. Network Performance of several network elements of the originating and terminating network(s) contribute to the QoS as perceived by the customer including terminals and terminal attachments. In order to offer the customer a certain QoS the serving network need to take into account network performance components of their network, reflect the performance of the terminal and ad sufficient margin for the terminating networks in case network performance requirements cannot be negotiated.

As far as the QoS to the subscriber is concerned network elements have to provide sufficient performance (reflecting possible performance constraints in terminating networks) so that the PLMN cannot be considered as a bottleneck.

This section outlines the requirements on bearer services in two main groups;

– Requirements on information transfer, which characterise the networks transfer capabilities for transferring user data between two or more access points.

– Information quality characteristics, which describe the quality of the user information transferred between two or more access points.

It shall be possible to negotiate / re negotiate the characteristics of a bearer service at session / connection establishment and during an on going session / connection.

It shall be possible to allocate a particular QoS to any specific service of the user. The association between services and QoS can be handled either network based or UE based. In the case of a UE based association it shall be possible to be programmed by the Home Environment operator into the ME or the USIM. If the association exists in the UE the specific QoS for the invoked service shall be requested at session / connection establishment.

5.2.1 Information transfer

Connection oriented / connectionless services

Both Connection oriented and connectionless services shall be supported.

Traffic type: It is required that the bearer service provides one of the following:

– guaranteed/constant bit rate,

– non-guaranteed/dynamically variable bit rate, and

– real time dynamically variable bit rate with a minimum guaranteed bit rate..

Real time and non real time applications shall be supported.

– Real time video, audio and speech shall be supported. This implies the:

– ability to provide a real time stream of guaranteed bit rate, end to end delay and delay variation.

– ability to provide a real time conversational service of guaranteed bit rate, end to end delay and delay variation.

– Non real time interactive and file transfer service shall be supported. This implies the:

– ability to support message transport with differentiation as regards QoS between different users.

– Multimedia applications shall be supported. This implies the:

– ability to support several user flows to/from one user having different traffic types (e.g. real time, non real time)

Traffic characteristics

It shall be possible for an application to specify its traffic requirements to the network by requesting a bearer service with one of the following configurations

1) Point-to-Point

– Uni-Directional

– Bi-Directional

– Symmetric

– Asymmetric

2) Uni-Directional Point-to-Multipoint

– Multicast

– Broadcast

A multicast topology is one in which sink parties are specified before the connection is established, or by subsequent operations to add or remove parties from the connection. The source of the connection shall always be aware of all parties to which the connection travels.

A broadcast topology is one in which the sink parties are not always known to the source. The connection to individual sink parties is not under the control of the source, but is by request of each sink party.

NOTE: Point-to-multipoint services are not supported by release 99 specifications.

In the case of a mobile termination with several active bearer services simultaneously, it shall be possible for each bearer service to have independent configurations and source/sink parties.

5.2.2 Information Quality

Information quality a characterises the bit integrity and delay requirements of the applications.

Other parameters may be needed.

Maximum transfer delay

Transfer delay is the time between the request to transfer the information at one access point to its delivery at the other access point. In clause 5.5 requirements on maximum transfer delay is defined.

Delay variation

The delay variation of the information received information over the bearer has to be controlled to support real-time services. The possible values for delay variation are not a limited set, but a continuous range of values.

Bit error ratio

The ratio between incorrect and total transferred information bits. The possible values for Bit error ratio are not a limited set, but a continuous range of values.

Data rate

The data rate is the amount of data transferred between the two access points in a given period of time.

5.3 Supported bit rates

It shall be possible for one application to specify its traffic requirements to the network by requesting a bearer service with any of the specified traffic type, traffic characteristics, maximum transfer delay, delay variation, bit error ratios & data rates. It shall be possible for the network to satisfy these requirements without wasting resources on the radio and network interfaces due to granularity limitations in bit rates.

It shall be possible for one mobile termination to have several active bearer services simultaneously, each of which could be connection oriented or connectionless.

The only limiting factor for satisfying application requirements shall be the cumulative bit rate per mobile termination at a given instant (i.e. when summing the bit rates of one mobile termination’s simultaneous connection oriented and connectionless traffic, irrespective of the traffic being real time or non real time) in each radio environment:

– At least 144 kbits/s in satellite radio environment (Note 1).

– At least 144 kbits/s in rural outdoor radio environment.

– At least 384 kbits/s in urban/suburban outdoor radio environments.

– Greater than 2 Mbits/s in urban/suburban outdoor radio environments (Note 2 and 3).

– At least 2048 kbits/s in indoor/low range outdoor radio environment. (Note 2)

– Greater than 2 Mbits/s in indoor/low range outdoor radio environment (Note 2 and 3).

NOTE 1: This Peak Bit Rate may only be achieved in a nomadic operating mode.

NOTE 2: Not supported by GERAN.

NOTE 3: Peak instantaneous rate for UTRAN supporting HSDPA.

5.4 Range of QoS requirements

It shall be possible for one application to specify its QoS requirements to the network by requesting a bearer service with any of the specified traffic type, traffic characteristics maximum transfer delay, delay variation, bit error ratios & data rates.

The following table indicates the range of values that shall be supported. These requirements are valid for both connection and connectionless traffic. It shall be possible for the network to satisfy these requirements without wasting resources on the radio and network interfaces due to granularity limitations in QoS.

	Real Time (Constant Delay)	Non Real Time (Variable Delay)
Operating environment	BER/Max Transfer Delay	BER/Max Transfer Delay
Satellite (Terminal relative speed to ground up to 1000 km/h for plane)	Max Transfer Delay less than 400 ms BER 10-3 – 10-7 (Note 1)	Max Transfer Delay 1200 ms or more (Note 2) BER = 10-5 to 10-8
Rural outdoor (Terminal relative speed to ground up to 500 km/h) (Note 3)	Max Transfer Delay 20 – 300 ms BER 10-3 – 10-7 (Note 1)	Max Transfer Delay 150 ms or more (Note 2) BER = 10-5 to 10-8
Urban/ Suburban outdoor (Terminal relative speed to ground up to 120 km/h)	Max Transfer Delay 20 – 300 ms BER 10-3 – 10-7 (Note 1)	Max Transfer Delay 150 ms or more (Note 2) BER = 10-5 to 10-8
Indoor/ Low range outdoor (Terminal relative speed to ground up to 10 km/h)	Max Transfer Delay 20 – 300 ms BER 10-3 – 10-7 (Note 1)	Max Transfer Delay 150 ms or more (Note 2) BER = 10-5 to 10-8
NOTE 1: There is likely to be a compromise between BER and delay. NOTE 2: The Max Transfer Delay should be here regarded as the target value for 95% of the data. NOTE 3: The value of 500 km/h as the maximum speed to be supported in the rural outdoor environment was selected in order to provide service on high speed vehicles (e.g. trains). This is not meant to be the typical value for this environment (250 km/h is more typical).

5.5 Supported End User QoS

This section outlines the QoS requirements that shall be provided to the end user / applications and describes them as requirements between communicating entities (i.e. end to end). The QoS values in the tables represent end to end performance, including mobile to mobile calls and satellite components. Delay values represent one -way delay (i.e. from originating entity to terminating entity). The values included in the following tables are commonly accepted values from an end-user viewpoint [12]. The delay contribution within the mobile network should be kept to minimum since there may be additional delay contributions from external networks.

Figure 2 below summarises the major groups of application in terms of QoS requirements. Applications and new applications may be applicable to one more groups. However, there is no strict one-to-one mapping between the groups of application/service defined in this TS and the traffic classes as defined in TS 23.107 [14]. For instance, an Interactive application/service can very well use a bearer of the Conversational traffic class if the application/service or the user has tight requirements on delay.

Figure 2: Summary of applications in terms of QoS requirements

The following tables further elaborate end user / application QoS requirements.

Table 1: End-user Performance Expectations – Conversational / Real-time Services

Medium	Application	Degree of symmetry	Data rate	Key performance parameters and target values
				End-to-end One-way Delay	Delay Variation within a call	Information loss
Audio	Conversational voice	Two-way	4-25 kb/s	<150 msec preferred <400 msec limit Note 1	< 1 msec	< 3% FER
Video	Videophone	Two-way	32-384 kb/s	< 150 msec preferred <400 msec limit Lip-synch : < 100 msec		< 1% FER
Data	Telemetry – two-way control	Two-way	<28.8 kb/s	< 250 msec	N.A	Zero
Data	realtime games	Two-way	< 60 kb/s Note 2	< 75 msec preferred	N.A	< 3% FER preferred, < 5% FER limit Note 2
Data	Telnet	Two-way (asymmetric)	< 1 KB	< 250 msec	N.A	Zero

NOTE 1: The overall one way delay in the mobile network (from UE to PLMN border) is approximately 100msec.

NOTE 2: These values are considered the most demanding ones with respect to delay requirements (e.g. supporting First Person Shooter games). Other types of games may require higher or lower data rates and more or less information loss but can tolerate longer end-to-end delay

Table 2: End-user Performance Expectations – Interactive Services

Medium	Application	Degree of symmetry	Data rate	Key performance parameters and target values
				One-way Delay	Delay Variation	Information loss
Audio	Voice messaging	Primarily one-way	4-13 kb/s	< 1 sec for playback < 2 sec for record	< 1 msec	< 3% FER
Data	Web-browsing – HTML	Primarily one-way		< 4 sec /page	N.A	Zero
Data	Transaction services – high priority e.g. e-commerce, ATM	Two-way		< 4 sec	N.A	Zero
Data	E-mail (server access)	Primarily One-way		< 4 sec	N.A	Zero

Table 3: End-user Performance Expectations – Streaming Services

Medium	Application	Degree of symmetry	Data rate	Key performance parameters and target values
				Start-up Delay	Transport delay Variation	Packet loss at session layer
Audio	Speech, mixed speech and music, medium and high quality music	Primarily one-way	5-128 kb/s	< 10 sec	< 2sec	< 1% Packet loss ratio
Video	Movie clips, surveillance, real-time video	Primarily one-way	20-384 kb/s	< 10 sec	<2 sec	< 2% Packet loss ratio
Data	Bulk data transfer/retrieval, layout and synchronisation information	Primarily one-way	< 384 kb/s	< 10 sec	N.A	Zero
Data	Still image	Primarily one-way		< 10 sec	N.A	Zero

5.6 Radio Interface optimisation

The following requirements shall lead the radio interface optimisation process;

– support of high bit rate (around the Peak Bit Rate), bursty, asymmetric, non-real time bearer capabilities;

– support of high bit rate (around the Peak Bit Rate), bursty, asymmetric, real time bearer capabilities;

– the ability to extend or reduce the bandwidth associated with a bearer capability in order to adapt to bit rate or radio condition variations, and to add or drop service components.

However, the services provided by existing systems (speech in particular) shall be supported in a spectrally efficient manner (at least as efficiently as included in GSM specifications) for the same quality of service.

In order to allow the support of flexible, bandwidth on demand services, bearer services should be provided with the finest possible granularity that can be efficiently supported.

5.7 Service Based QoS Control of IP based Services

Many IP based services and applications will negotiate the resources required in an end to end manner on the application level. It is essential for the PLMN to provide the capability of ensuring that the resources provided and charged for shall be in line with that authorized by the service and subscription.

The PLMN

– shall be able to dynamically allocate QoS according to service needs and subscription information.

– shall be able to give differentiated policing for the traffic within an APN. That is, the policing shall be on a per service flow basis (i.e. on the basis of specific flows of IP packets identified by the service).

– shall control the requested QoS parameters based on the invoked service needs and subscription information.

– shall facilitate service-flow level charging.

Any solution:

– shall support roaming users

– should minimise UE dependencies and optimize usage of network resources

5.8 QoS control for IP bearer service

In order to have efficient use of radio resources shared amongst terminals, it shall be possible for a PLMN to apply a limit to the cumulative bit rate per subscriber at a given instant for non-real time services (i.e. when summing the bit rates of one subscriber’s simultaneous non-real time traffic).

5.9 Ability to effectively handle a variety of different types of IP traffic

The PLMN shall support both IPv4 and IPv6 connectivity. IPv4 only, IPv6 only and dual mode (IPv4/IPv6) terminals should be supported. Interworking between terminals, servers and access systems supporting different versions of IP shall be possible. Mobility between access systems supporting different IP versions shall be supported with minimal network/terminal impacts.

The PLMN shall support simultaneous IPv4 and IPv6 usage for a single bearer connecting to the same PDN through the same APN.

The operator shall be able to control whether or not an IPv4 only terminal is allowed access to the network.

Service continuity of subscriber IP sessions shall be supported during UE handovers from one IP access network to another IP access network, regardless of whether the new IP access network supports the same version of IP as the old IP access network.

The PLMN shall be able to handle user-to-server traffic, user-to-user traffic and user-to-group traffic.

The PLMN shall be able to handle different types of IP traffic, such as real-time (e.g. VoIP), non-real time traffic (e.g. Web browsing), and mission critical traffic (e.g. M-Commerce).

Large number of

terminals or appliances (e.g. sensors & tags)

Omnipresent Services

PC

Sensor

Traffic sign

Sensor

Status Report Traffic

Tele

–

metering

Service Traffic

High frequency

trickle traffic

–

Evolved Packet System

Figure 1: Traffic models of omnipresent services

5.10 IP address support

The PLMN shall have the ability to support both private and public IPv4 and IPv6 addresses. User device IP addresses should normally be allocated dynamically by the network operator and managed without user intervention. For business critical applications, and for firewall configuration simplification purposes, it shall be possible for a user to be allocated a static IP address; the static address shall be assigned by the network operator. Details of an assigned static IP address shall be maintained with the subscriber’s records in the HLR/HSS.