Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 22.105  Word version:  16.0.0

Top   Top   Up   Prev   None
1…   4…   5…   6…   A…

 

A  Examples of services built from service capabilities featuresWord‑p. 27
Call Barring
In standard GSM, the Call Barring services allow to prevent outgoing calls to certain sets of destinations, based on the number dialled and whether the user is roaming. It is proposed that this service allows to block outgoing calls based on a wider range of parameters which could include factors such as the time of day, day of week, location, type of call requested, cost of the service and/or destination. This would allow to develop Call Barring services tailored to business and personal markets to avoid abuse.
This service is invoked during the initial outgoing call set-up procedure and allow the call to be blocked prior to incurring any charges. This Service can be applied to any teleservice for both connection-oriented and connectionless-oriented services.
Call Filtering/Forwarding
In standard GSM, there is no call filtering service. All calls are presented to the user unless a call forwarding service is used to re-direct calls; there is no different call handling depending on the incoming call parameters (although differentiation on call type (voice/data) is possible).
The call filtering service allows the control of whether incoming calls are accepted, forwarded or terminated. The parameters which can be used to determine the final destination of a call may include the caller ID (CLI), original number dialled, time of day, current user location/network, user profile settings and current state of the terminal.
This service shall be two-stage; immediate call filtering (handled regardless of whether the terminal is online or not) and late call filtering (handled only if the terminal is online). It shall be possible to create and operate new call filtering services which can access any of the key parameters to handle calls in this way.
Hold
This service allows an established call to be maintained, whilst suspending use of the bearer from the incoming access point of the network. This saves on both air interface and network traffic resources when a call is temporarily suspended. The incoming access point in the network means either the originating terminal, or interworking point with another network.
Transfer
This service allows either an established or held call to be redirected to another destination. This may either be used by setting up a new call to the destination first, or simply redirecting the existing call to the new destination. It shall be possible to revert such a call back to the diverting terminal at any time before it is accepted (answered) by the new destination. The system shall ensure that an optimal traffic route is used after the call has been answered by its new (final) destination.
Call-back When Free
This service can be invoked where a call (or a connectionless message) cannot be delivered to its destination because it is in use. The system shall inform the requesting entity when the destination is next able to accept the call, allowing a new call to be originated. This allows existing GSM services, such as Call-back When Free to be implemented. Where multiple requests are outstanding for a terminal which becomes available, the system shall determine in which order the requests are handled, probably in a serial manner. Ideally, it shall be possible to create the service logic which determines the order used from a range of accessible parameters.
Up

B  Description and analysis of communication schemesWord‑p. 28
This annex gives a high level classification and description of communications requirements from end users and applications.

B.1  Communication schemes

The requirements on bearer services are based on an analysis of user and application needs. Four end-user groups are identified according to four distinctly different communication schemes; Conversational - real time, Interactive services, Streaming services and Background services.

B.2  QoS related performance requirements for example end user applications

A typical user is not concerned with how a particular service is provided. However, the user is interested in comparing one service with another in terms of universal, user-oriented performance parameters which apply to any end-to-end service. From a user's perspective, performance should be expressed by parameters which:
  • Focus on user-perceivable effects, rather than their causes within the network
  • Are independent of the networks internal design
  • Take into account all aspects of the service from the user's point of view which can be objectively measured at the service access point
  • Can be assured to a user by the service providers(s)
With these considerations in mind, this section examines the requirements of typical end user applications that can be expected.
Up

B.2.1  Performance requirements for conversational real-time

The most well known use of this scheme is telephony speech (e.g. GSM), but with Internet and multimedia a number of new applications will require this scheme, for example voice over IP and video conferencing tools. Real time conversation is always performed between peers (or groups) of live (human) end-users. This is the only scheme where the required characteristics are strictly given by human perception (the senses). Therefore this scheme raises the strongest and most stringent QoS requirements.
The real time conversation scheme is characterised by that the transfer time shall be low because of the conversational nature of the scheme and at the same time that the time relation (variation) between information entities of the stream shall be preserved in the same way as for real time streams. The maximum transfer delay is given by the human perception of video and audio conversation. Therefore the limit for acceptable transfer delay is very strict, as failure to provide low enough transfer delay will result in unacceptable lack of quality. The transfer delay requirement is therefore both significantly lower and more stringent than the round trip delay of the interactive traffic case.
Real time conversation - fundamental characteristics for QoS:
  • preserve time relation (variation) between information entities of the stream
  • conversational pattern (stringent and low delay)
The resulting overall requirement for this communication scheme is to support conversational real time services with low transfer delay as given by the human perception. (There are less hard requirements on packet loss ratio.)
A real-time streaming application is one that delivers time-based information in real-time, where time-based information is user data that has an intrinsic time component. Video, audio and animation are examples of time-based information, in that they consist of a continuous sequence of data blocks that shall be presented to the user in the right sequence at pre-determined instants.
Conversational voice
Audio transfer delay requirements depends on the level of interactivity of the end users. To preclude difficulties related to the dynamics of voice communications, ITU-T Recommendation G.114 [19] recommends the following general limits for one-way transmission time (assuming echo control already taken care of):
0 to 150 ms
preferred range [<30ms, user does not notice any delay at all, <100ms, user does not notice delay if echo cancellation is provided and there are no distortions on the link]
150 to 400 ms
acceptable range (but with increasing degradation)
above 400 ms
unacceptable range
The human ear is highly intolerant of short-term delay variation (jitter) it is therefore paramount that this is reduced as lower level as is practical. A limit as low as 1 msec is suggested as a target.
Requirements for information loss are influenced by the fact that the human ear is tolerant to a certain amount of distortion of a speech signal. It is has been suggested in studies that acceptable performance is typically obtained with frame erasure rates (FER) up to 3 %.
A connection for a conversation normally requires the allocation of symmetrical communication resources, with the average hold time of a call being in the region of 2 minutes.
Videophone
Videophone implies a full-duplex system, carrying both video and audio and intended for use in a conversational environment. As such, in principle the same delay requirements as for conversational voice will apply, i.e. no echo and minimal effect on conversational dynamics, with the added requirement that the audio and video must be synchronised within certain limits to provide "lip-synch" (i.e. synchronisation of the speaker's lips with the words being heard by the end user). In fact, due to the long delays incurred in even the latest video codecs, it will be difficult to meet these requirements.
Once again, the human eye is tolerant to some loss of information, so that some degree of packet loss is acceptable depending on the specific video coder and amount of error protection used. It is expected that the latest video codecs will provide acceptable video quality with frame erasure rates up to about 1%.
Interactive games
Requirements for interactive games are obviously very dependent on the specific game, but it is clear that demanding applications will require very short delays, and a value of 250 msec is proposed, consistent with demanding interactive applications.
Two-way control telemetry
Two-way control telemetry is included here as an example of a data service which does require a real-time streaming performance. Clearly, two-way control implies very tight limits on allowable delay and a value of 250 msec is proposed, but a key differentiator from the voice and video services in this category is the zero tolerance for information loss (obvious if you are controlling an important industrial process, for example).
Telnet
Telnet is included here with a requirement for a short delay in order to provide essentially instantaneous character echo-back.
Up

B.2.2  Performance requirements for Interactive ServicesWord‑p. 30
When the end-user, that is either a machine or a human, is on line requesting data from remote equipment (e.g. a server), this scheme applies. Examples of human interaction with the remote equipment are: web browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: polling for measurement records and automatic data base enquiries (tele-machines).
Interactive traffic is the other classical data communication scheme that on an overall level is characterised by the request response pattern of the end-user. At the message destination there is an entity expecting the message (response) within a certain time. Round trip delay time is therefore one of the key attributes. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate).
Interactive traffic - fundamental characteristics for QoS:
  • request response pattern
  • preserve payload content
The resulting overall requirement for this communication scheme is to support interactive non-real time services with low round-trip delay.
Voice messaging and dictation
Requirements for information loss are essentially the same as for conversational voice, but a key difference here is that there is more tolerance for delay since there is no direct conversation involved. The main issue, therefore becomes one of how much delay can be tolerated between the user issuing a command to replay a voice message and the actual start of the audio. There is no precise data on this, but a delay of the order of a few seconds appears reasonable for this application.
Data
Although there may be some exceptions, as a general rule it is assumed that from a user point of view, a prime requirement for any data transfer application is to guarantee essentially zero loss of information. At the same time, delay variation is not applicable. The different applications therefore tend to distinguish themselves on the basis of the delay which can be tolerated by the end-user from the time the source content is requested until it is presented to the user.
Web-browsing
In this category we will refer to retrieving and viewing the HTML component of a Web page, other components eg images, audio/video clips are dealt with under their separate categories. From the user point of view, the main performance factor is how fast a page appears after it has been requested. A value of 2-4 seconds per page is proposed, however improvement on these figures to a target figure of 0.5 seconds wound be desirable.
High-priority transaction services (E-commerce)
The main performance requirement here is to provide a sense of immediacy to the user that the transaction is proceeding smoothly. A value of 2-4 seconds is suggested to be acceptable to most users.
E-mail (server access)
E-mail is generally thought to be a store and forward service which in principle can tolerate delays of several minutes or even hours. However, it is important to differentiate between communications between the user and the local email server and server to server transfer. When the user communicates with the local mail server, there is an expectation that the mail will be transferred quite rapidly, although not necessarily instantaneously. Consistent with the research findings on delay tolerance for Web-browsing, a requirement of 2-4 seconds is proposed.
Up

B.2.3  Performance requirements for streaming servicesWord‑p. 31
When the user is looking at (listening to) video (audio) the scheme streams applies. The real time data flow is always aiming at a live (human) destination. It is a one way transport.
This scheme is one of the newcomers in data communication, raising a number of new requirements in both telecommunication and data communication systems. First of all it is a mainly unidirectional stream with high continuous utilisation (i.e. having few idle/silent periods.) It is also characterised by that the time relations (variation) between information entities (i.e. samples, packets) within a flow must be preserved, although it does not have any requirements on low transfer delay.
The delay variation of the end-to-end flow must be limited, to preserve the time relation (variation) between information entities of the stream. But as the stream normally is time aligned at the receiving end (in the user equipment), the highest acceptable delay variation over the transmission media is given by the capability of the time alignment function of the application. Acceptable delay variation is thus much greater than the delay variation given by the limits of human perception.
Real time streams - fundamental characteristics for QoS:
  • unidirectional continuous stream
  • preserve time relation (variation) between information entities of the stream
The resulting overall requirement for this communication scheme is to support streaming real time services having unidirectional data flows with continuous utilisation. (There are less stringent requirements on delay and packet loss ratio, i.e. the ratio of lost or corrupted packets out of all packets sent.)
Audio streaming
Audio streaming is expected to provide better quality than conventional telephony, and requirements for information loss in terms of packet loss will be correspondingly tighter. However, as with voice messaging, there is no conversational element involved and delay requirements can be relaxed, even more so than for voice-messaging.
One-way video
The main distinguishing feature of one-way video is that there is no conversational element involved, meaning that the delay requirement will not be so stringent, and can follow that of streaming audio.
Bulk data
This category includes file transfers, and is clearly influenced by the size of the file. As long as there is an indication that the file transfer is proceeding, it is reasonable to assume some what longer tolerance to delay than for a single Web-page.
Still image
This category includes a variety of encoding formats, some of which may be tolerant to information loss since they will be viewed by a human eye. However, given that even single bit errors can cause large disturbances in other still image formats, it is argued that this category should in general have zero information loss. However, delay requirements for still image transfer are not stringent, given that the image tends to be built up as it is being received, which provides an indication that data transfer is proceeding.
Telemetry (monitoring)
Monitoring covers a wide range of applications, but in this category it is taken to apply to relatively low priority activities, e.g. status updating, rather than control.
Up

B.2.4  Performance requirements for Background applicationsWord‑p. 32
When the end-user, that typically is a computer, sends and receives data-files in the background, this scheme applies. Examples are background delivery of E-mails, SMS, download of databases and reception of measurement records.
Background traffic is one of the classical data communication schemes that on an overall level is characterised by that the destination is not expecting the data within a certain time. The scheme is thus more or less delivery time insensitive. Another characteristic is that the content of the packets must be transparently transferred (with low bit error rate).
Background traffic - fundamental characteristics for QoS:
  • the destination is not expecting the data within a certain time
  • preserve payload content
The resulting overall requirement for this communication scheme is to support non-real time services without any special requirement on delay.
A background application is one that does not carry delay information. In principle, the only requirement for applications in this category is that information should be delivered to the user essentially error free. However, there is still a delay constraint, since data is effectively useless if it is received too late for any practical purpose.
Fax
Fax is included in this category since it is not normally intended to be an accompaniment to real-time communication. Nevertheless, there is an expectation in most business scenarios that a fax will be received within about 30 seconds. The information loss requirement is based on established wireline requirements for a Group 3 fax. As for the symmetry this should provide the required through put in the sending direction and the control signalling in backwards direction, hence an asymmetric connection is required.
Low priority transaction services
An example in this category is Short Message Service (SMS). 30 seconds is proposed as an acceptable delivery delay value.
Email (server to server)
This category is included for completeness, since as mentioned earlier, the prime interest in email is in the access time. There is a wide spread in user expectation, with a median value of several hours.
Up

B.3  Adaptability and bearer service negotiation

Applications using the interactive or real time conversational communication schemes can also be described according to their possibilities for adapting to different environmental conditions as follows:
  • Rigid applications; these applications can not adapt at all (e.g. GSM full rate speech.)
  • Adaptive applications; these applications can adapt to the environment; they therefore require the network to support service negotiation. (e.g. multi-rate speech codecs)
  • Elastic applications; these applications adapt totally to the environment and do therefore not require service negotiation (e.g. web browsing).
The resulting overall requirement is to support service negotiation.
Up

$  Change historyWord‑p. 33

Up   Top