Content for TS 22.105 Word version: 16.0.0
5 Bearer Services
5.1 Definition of bearer services
5.2 Description of bearer services
5.3 Supported bit rates
5.4 Range of QoS requirements
5.5 Supported End User QoS
5.6 Radio Interface optimisation
5.7 Service Based QoS Control of IP based Services
5.8 QoS control for IP bearer service
5.9 Ability to effectively handle a variety of different types of IP traffic
5.10 IP address support
...
...
5 Bearer Services Word‑p. 11
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 TS 22.060. 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
-
Point-to-Point
-
Uni-Directional
-
Bi-Directional
-
Symmetric
-
Asymmetric
-
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.
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 Word‑p. 12
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 Word‑p. 13
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).
5.4 Range of QoS requirements Word‑p. 14
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.
Operating environment
Real Time (Constant Delay)
BER/Max Transfer Delay
Non Real Time (Variable 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
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 5.5-1 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. 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.
[not reproduced yet]
Figure 5.5-1: Summary of applications in terms of QoS requirements
The following tables further elaborate end user / application QoS requirements.
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
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
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 Word‑p. 16
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 Word‑p. 17
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).
[not reproduced yet]
Figure 5.9-1: Traffic models of omnipresent services
5.10 IP address support Word‑p. 18
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.
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 TS 22.060. 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.
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:
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
- 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 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)
-
Point-to-Point
- Uni-Directional
-
Bi-Directional
- Symmetric
- Asymmetric
-
Uni-Directional Point-to-Multipoint
- Multicast
- Broadcast
5.2.2 Information Quality Word‑p. 12
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.
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 Word‑p. 13
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).
5.4 Range of QoS requirements Word‑p. 14
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.
Operating environment
Real Time (Constant Delay)
BER/Max Transfer Delay
Non Real Time (Variable 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
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 5.5-1 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. 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.
[not reproduced yet]
Figure 5.5-1: Summary of applications in terms of QoS requirements
The following tables further elaborate end user / application QoS requirements.
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
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
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 Word‑p. 16
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 Word‑p. 17
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).
[not reproduced yet]
Figure 5.9-1: Traffic models of omnipresent services
5.10 IP address support Word‑p. 18
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.
- 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).
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.
Operating environment
Real Time (Constant Delay)
BER/Max Transfer Delay
BER/Max Transfer Delay
Non Real Time (Variable Delay)
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)
BER 10-3 - 10-7(Note 1)
Max Transfer Delay 1200 ms or more (Note 2)
BER = 10-5 to 10-8
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)
BER 10-3 - 10-7 (Note 1)
Max Transfer Delay 150 ms or more (Note 2)
BER = 10-5 to 10-8
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)
BER 10-3 - 10-7 (Note 1)
Max Transfer Delay 150 ms or more (Note 2)
BER = 10-5 to 10-8
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)
BER 10-3 - 10-7 (Note 1)
Max Transfer Delay 150 ms or more (Note 2)
BER = 10-5 to 10-8
BER = 10-5 to 10-8
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 5.5-1 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. 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.
[not reproduced yet]
Figure 5.5-1: Summary of applications in terms of QoS requirements
The following tables further elaborate end user / application QoS requirements.
Medium
Application
Degree of symmetry
Data rate
Key performance parameters and target values
End-to-end One-way Delay
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
Medium
Application
Degree of symmetry
Data rate
Key performance parameters and target values
One-way Delay
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
Medium
Application
Degree of symmetry
Data rate
Key performance parameters and target values
Start-up Delay
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 Word‑p. 16
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 Word‑p. 17
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).
[not reproduced yet]
Figure 5.9-1: Traffic models of omnipresent services
5.10 IP address support Word‑p. 18
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.
- 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.
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.
- 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).
[not reproduced yet]
Figure 5.9-1: Traffic models of omnipresent services
5.10 IP address support Word‑p. 18
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.