5 Specific Interaction Requirements

23.2273GPPApplication and user interaction in the User Equipment (UE)Principles and specific requirementsRelease 5TS

The following clauses detail specific interaction requirements.

5.1 Bearer Independent Data Transfer: Radio Access bearers

Bearer Independent Data Transfer, using bearers over the Uu reference point, is a (U)SAT feature that allows a (U)SAT application to request the MT to set up and manage a data channel over a CSD, GPRS, SMS or USSD bearer using information provided by the (U)SAT application. Once the call is established, data may be transferred through that data call. The details for the (U)SIM-(U)SAT/ME interface are specified in 3GPP TS 31.101 [4], 31.102 [5], and 31.111 [6]. The Service Requirements for this are specified in 3GPP TS 22.038 [7].

5.1.1 Interaction between Core MT functions and Bearer Independent Data Transfer Service using Radio Access bearers

When a Bearer Independent Data Transfer Service is requested by a (U)SAT application, the MT shall:

  • If the MT is idle, set up the data channel as requested, indicating to the user by appropriate means, e.g., with an icon, that one or more calls are in progress and confirming to the (U)SAT application.
  • If the MT is not idle and can not service the request without negative impact on ongoing services, then the MT shall indicate to the (U)SAT application that the data channel can not be set up. However, if the user has indicated a preference for servicing such requests despite the negative impact then the MT may proceed as in the bullet point above.
  • If the user requests that the call be terminated via MMI or other interface, then the call shall be terminated and the (U)SAT application shall be informed.
  • If an external device (TE, Bluetooth device etc.) requests the same resource then that request shall be denied.

The above behaviour may be modified by a change of user preferences, for example the user may request the MT to deny access by the (U)SAT application to a data channel, or the user may request the MT to prioritise a particular external device such that a call set up by a (U)SAT application is cleared in order for the external device to be able to make a call.

5.2 Bearer Independent Data Transfer: local bearers

Bearer Independent Data Transfer, using local bearers, is a (U)SAT feature that allows a (U)SAT application to request the MT to set up and manage a data channel over local links such as Bluetooth, IrDA, RS232 or USB, using information provided by the (U)SAT application. Once the channel is open (local link), data may be transferred through the open channel. The details for the (U)SIM- (U)SAT/ME interface are specified in 3GPP TS 31.101 [4], 31.102 [5], and 31.111 [6]. The Service Requirements for this are specified in 3GPP TS 22.038 [7].

5.2.1 Interaction between Core ME functions and Bearer Independent Data Transfer Service using local bearers

When a Bearer Independent Data Transfer Service over a local link is requested by a (U)SAT application, the MT shall:

  • If the MT can set up the local channel as requested, the user shall be notified by appropriate means, e.g., with an icon, that one or more channels are in progress and confirming to the (U)SAT application.
  • If the MT cannot service the request without negative impact on ongoing services, then the MT shall indicate to the (U)SAT application that the data channel cannot be opened. However, if the user has indicated a preference for servicing such requests despite the negative impact then the MT may proceed as in the bullet point above.
  • If the user requests that the channel be closed via MMI or other interface, then the channel shall be closed and the (U)SAT application shall be informed.

The above behaviour may be modified by a change of user preferences, for example the user may request the MT to deny access by the (U)SAT application to a data channel over a local link, or the user may request the MT to prioritise a particular external device such that a channel open by a (U)SAT application is cleared in order for the external device to be able to make open a channel.

5.2.2 Security requirements on (U)SAT Bearer Independent Data Transfer using local bearers

The local link connection, via Bluetooth, IrDA, USB or RS232, set up from a (U)SAT application shall follow the same security requirements as if the link were established by an application in the MT.

It is important that the requirements stated in 5.3 “Services and applications external to the MT” are fulfilled when a Bearer Independent Data Transfer via local link bearer is controled by a (U)SAT application.

The secret key and the authentication algorithm cannot be transferred out from the UICC, where the (U)SAT application resides, over the established local link.

5.3 Services and applications external to the MT

In the tele- and datacom community there exist today use cases for moving internal interfaces out of the MT; they are required to fulfil user expectations of what services and features 3G MTs should offer.

However, discussions on security clearly show that services should be terminated in the MT, while applications can, as today, terminate in the TE. A possible UE functionality split should not allow internal interfaces (including USIM) to be moved to external interfaces, neither using USAT local link nor other interfaces.

This is a precaution that shall be taken until suitable procedures against misuse have been found and standardised.

Annex A (informative):
Interaction handling

In the present document we illustrate possible types of interaction handling for a MT that already can be required or that currently are being developed in standards and industry fora. Although it is probable that only a subset of these entities will exist at the same time, there is no way of knowing the particular combination of applications or a particular users needs relative to this in advance; a general way to handle the co-existence must still be defined.

A framework, defining general rules for handling this co-existence of several external functions is outlined in the present document. The framework states requirements for the behaviour of the external functions as well as principles for the co-existence as such. As an example, several of the external functions below, or protocols used by them (e.g., the AT‑commands) assume a one-to-one relation between them and the MT Core Functions, implying a lack of specified mechanisms to handle a multitask environment.

A.1 The model approach

The model below proposes a conceptual split, meaning that the entities and their interfaces are logical and need not correspond to any physical division. Before the figure is presented some clarifications and general comments are needed:

  • The MT Core Functions should be understood as the (collection of) software functions that contain the central logic for the MT, including for instance the scheduling of events.
  • With external event is meant interaction that an application/peripheral wants (requests/commands), as well as necessary handling of network signalling, user request via the keys, etc. External does not imply whether an external interface is used or not.
  • Some network signalling is easy to refer to basic network functions, such as Location Update, while other signalling has been invoked by an application.
  • The user can interact intervene directly via keys, etc. This is indicated with the Manual User Interaction entity. The user can of course do the same via, e.g., a PC or a MExE application, but the events that such actions create is here viewed like the other events that these entities can create.
  • The USIM general Smart Card Functions are split into several logical entities: the Transport Layer Security, meaning "basic" 2G/3G security; the USIM Application Toolkit; USIM Application Toolkit Run AT-command; and other functions, such as the WIM, the WAP Identity Module, that is being specified.
  • The TE, Terminal Equipment, is a PC or another piece of equipment that can run applications independently.
  • An Intelligent Peripheral could be an advanced charger or a car hands-free installation.
  • The MExE entities are as defined in [2].
  • Other includes MT resident applications and allows for future applications, and, if that is needed for the model, could correspond to other external devices such as a microphone.
  • The interfaces as shown in the figure are logical. In practice the applications run in the MT, a TA or on its own separate platform, and the interfaces are then MT internal or external via a physical connector, IrDA, or Bluetooth.

Figure A.1 Example of External events that the MT Core Functions should handle

The figure shows the extent of the complexity that the MT will be expected to handle. It is obvious that a generic framework for conflicts, error handling and interactions is needed. In particular, the following issues can be noted:

  1. Priorities of the event handling – the MT does the scheduling and this should be according to the user’s preferences.
  2. User control – the user’s wanted / required interaction; his/her knowledge and control of the events; user integrity for instance for personal data, the MT position, etc.
  3. Trace-ability – which entity / application has caused a particular event. This information is required input to solve several of the other issues.
  4. Consistency – in the actions of the MT Core Functions relative to the specific application. Several applications and priority levels interact.
  5. The validity of commands – for instance call validity when the MT is in the Home PLMN or roaming.
  6. Network signalling aspects – how does for instance a dual mode MT treat applications specific to only one of the standards.
  7. It might be necessary to look into mechanisms for rejection and termination by the MT Core Function (upon user choice) for applications, calls etc.
  8. Testability – the MT manufacturer must be able to as far as possible verify the behaviour of the product, and this should be taken into consideration when the framework is specified. Conformance testing, however, is only relevant to the extent that already is tested.
  9. Security aspects – for the protection of the MT and the network mechanisms like authentication of the applications might be required.

Further, the entities have different characteristics; this can possibly be used by the framework definitions. The following can for instance be noted:

  1. Several of the entities work together with network nodes, some as slaves (e.g., SIM) and others invoking commands (e.g., WAP). Others, like the intelligent peripherals, only communicate "locally".
  2. The entities can be active or passive. In the latter case the MT has more knowledge about the expected behaviour, since they only execute functions upon request and cannot issue commands independently.
  3. Some events refer to “basic” network handling, some to manual user interaction, and others relate to application invoked functions. “Basic” network interaction should then have priority if such a distinction can be made. Consideration should be given to incoming calls.

Annex B (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2001-03

T#11

TP-010030

Approval of first version

1.0.0

4.0.0

2001-12

T#14

TP-010269

002

Correction in WAP Forum Reference

4.0.0

4.1.0

2001-12

T#14

TP-010269

003

Text added to Figure A.1

4.0.0

4.1.0

2001-12

T#14

TP-010269

001

Expansion of introduction and clarifications of scope

4.1.0

5.0.0

2001-12

T#14

TP-010269

004

Add the interaction requirements for USAT bearer indepenedent protocol via local links

4.1.0

5.0.0

2002-03

T#15

TP-020014

006

Alignment of UE architecture with 23.101

5.0.0

5.1.0