1 .Multimedia Messaging Service
After Short Message Service (SMS) and
Enhanced Messaging Service (EMS) described below, the next stage of messaging
evolution is MMS, which delivers an even richer messaging experience. MMS is
introduced in Release 99. It allows users to send and receive messages
exploiting a large array of media types e.g. text of almost unlimited length,
images, audio and video clips, while also making it possible to support new
content types as they become popular. MMS supports standard image formats such
as GIF (Graphics Interchange Format) and JPEG (Joint Picture Expert Group),
video formats such as MPEG 4 (Motion Picture Expert Group) and audio formats
and MIDI (Musical Instrument Digital
Interface). Multiple media elements can be combined into a composite single
message. Messages can be sent either to a mobile phone or to an e-mail address.
The main new network element of the
Multimedia Message Service Environment (MMSE) is the MMS Relay/Server which is responsible for storage
and handling of incoming and outgoing messages and for the transfer of messages
between different messaging systems. Other involved MMS elements are the MMS User Agent and MMS User databases. The functional descriptions of the involved MMS elements are
provided in TS 23.140 and for implementation of the MMS User Agent – MMS
Relay/Server interface a reference to the WAP
Implementation of MMS is given.
2.Location Services
Location Services is a feature providing
the ability to localise a terminal (MS - Mobile Station in GSM and
UE - User Equipment in UMTS). This location information is used to
provide services to the end-user (e.g. to offer a local map with indication of
closest restaurants, etc), for emergency services or for “internal clients”,
i.e. a UMTS network entity, like an RNC to direct the beam when space diversity
is used (not used at least up to Release 6).
The work on this feature was initiated by
T1P1, who worked on location services only for use in emergency situation. Then
their work was transferred to 3GPP who extend its scope to cover commercial
aspects as well. LCS was incompletely introduced for GSM in Release 98,
and was enhanced for GSM and adapted to UMTS in Release 99.
The location relies on three key functions:
the measurement of the radio signals, performed by the LMU (Location
Measurement Unit); the dialogue between the network and the external LCS
client, performed by the GMLC (Gateway MLC); and the calculation of the
position, performed by the SMLC (Serving Mobile Location Centre), also coordinating
the overall process. The architectures, both for GSM and for UMTS, are shown
below, extracted from TS 03.71 for the GSM (GERAN) aspects and from
TS 23.171 for the UMTS (UTRAN) aspects.
Legend: Red
lines and entities: interfaces and entities specific to LCS
Black
lines and entities: other interfaces and entities
The entity being tracked is the MS/UE at
the far left (shown as “UE” in the figure). The External LCS client at the far
right is the entity using the location information for himself (emergency
services) or to provide the commercial service to the User.
The label “alternative” on the figure means
that two options are possible:
- the LMU can be on the infrastructure side or can be a
stand-alone entity, communicating with the infrastructure re-using the
Radio interface using its own IMSI (even in the later case, the LMU
remains a network element),
- the SMLC can be connected to the BSC or to the MSC.
The options reflect lack of decision at
3GPP in the face of balanced advantages: in the first case, a type A LMU
(stand-alone entity) is easier to deploy but consumes radio resources,
contrarily to a type B LMU. With respect to the second option, connecting an
SMLC to the MSC reduces the number of connections (there are fewer MSC than
BSCs) but involves the MSC for relaying a user-access centric dialogue between
the BSC and the SMLC. This second option will disappear in later releases.
The flows for the External Client to get
the position of the User are the following:
CAMEL (Customized Applications for Mobile
The third phase of CAMEL enhances phase 2
by adding the following capabilities:
3.2. Multiple Subscriber Profile (MSP) based on CAMEL phase 3
Impacted
Specification: TS 22.097 on Advanced Addressing.
Multiple Subscriber Profile is an optional
service enabling mobile subscribers to have several profiles associated with a
single IMSI, with each profile being a subscription option. Each profile may be
used for mobile originated and mobile terminated calls.
Up to four different profiles can be
provisioned for a subscriber using the MSP feature. This allows the subscriber
to separate her telecommunication service needs into different identities (e.g.
business and home).
Separate charging for each profile is
possible. To this aim, a supporting visited network shall indicate on the
billing record the profile used.
For Release 99, the interaction with
Multicall was adapted.
3.3. Short Message Service
enhancements
This work items includes SMS for 3GPP terminals
which is fully compatible with the GSM SMS service. Additional enhancements and
improvements have been introduced e.g. Enhanced Messaging Service (EMS)
allowing small pictures, sounds, animations to be transferred via SMS.
- Text formatting: Alignment, Font size, Style
- Basic pictures: small (16*16 pixels), large (32*32 pixels) or
pictures of variable size, plain black and white
- Animations: Predefined, User Defined, 8*8 pixels and 16*16
pixels
- Sound: 10 different sounds Predefined, User Defined according
to the iMelody format
3.4.Mobile Station Execution Environment
MExE is a feature introduced in GSM Release
98, enhanced in GSM Release 99 to cover the following additional enhancements:
SIM MExE certificate management, security clarifications and QoS aspects.
This work item includes MExE for 3GPP
terminals which is fully compatible with GSM MExE Release 99, providing a
flexible Application Programmable Interfaces (API) for the terminal for third
party applications.
MExE provides a standardised execution
environment in an MS, and an ability to negotiate its supported capabilities
with a MExE service provider, allowing applications to be developed
independently of any MS platform. The MS can then be targeted at a range of
implementations for MExE from small devices with low bandwidth, limited
displays, low processor speeds, limited memory, MMI etc., to sophisticated with
a complete MExE execution environment.
A standardised means of negotiating the
MSs’ and network’s capabilities is supported. This negotiation permits the
mutual exchange of capabilities between the MS and the MExE server, and
possibly includes the service profile of the user and capabilities of the
network.
A network can be a transport bearer for the
negotiation, interaction and transferring of applications, applets and content
with the MS. It does not have to be the provider of the MExE services with
which the MS’s execution environment is interacting with. The network may also be
the intermediary between two MSs which are engaged in a MExE service with each
other, with the network effectively supplying the “pipe” and not playing a MExE
role in the connection.
Network nodes, nodes external to the
network, or even MSs are the entities which can interact with the MS’s
execution environment.
Central elements of the MExE specification
are the classmark concept, content negotiation and the security architecture.
MExE categorises devices by giving them different MExE classmarks. In R99,
two MExE classmarks are defined:
·
MExE classmark 1 - based on Wireless Application
Protocol (WAP) - requires limited input and output facilities (e.g. as simple
as a 3 lines by 15 characters display and a numeric keypad) on the client side,
and is designed to provide quick and cheap information access even over narrow
and slow data connections.
·
MExE classmark 2 - based on Personal-Java - provides
and utilises a run-time system requiring more processing, storage, display and
network resources, but supports more powerful applications and more flexible
MMIs. MExE Classmark 2 also includes support for MExE classmark 1 applications
(via the WML browser.)
Content negotiation
allows for flexible choice of formats available from a server or adaptation of
a service to the actual classmark
of a specific client device. Bi-directional capability negotiation
between the MExE Service Environment and MExE device (including MExE
classmark), supports the transfer of capabilities between the client and the
server.
In order to manage the MExE and prevent
attack from unfriendly sources or transferred applications unintentionally
damaging the MExE device a security architecture is specified. The basis of
MExE security is:
· A framework of permissions
which defines the permissions transferred MExE executables have within the MExE
MS;
·
the secure storage of these
permissions and permission types);
·
conditions within the execution
environment that ensure that MExE executables can only perform actions for
which they have permission.
The MExE permissions framework is as
follows (there is no implied hierarchy):
·
MExE Security Operator Domain (MExE executables
authorised by the HPLMN operator);
·
MExE Security Manufacturer Domain (MExE executables
authorised by the terminal manufacturer);
·
MExE Security Third Party Domain (trusted MExE
executables authorised by trusted third parties);
·
Support for the three domains is mandatory;
Untrusted MExE executables are not in a
specific domain, and have very reduced privileges.
3.5.Multicall
Multicall is a feature which allows several
simultaneous CS calls with dedicated bearers of independent traffic and
performance characteristics, e.g. it allows several CS data bearers to be bound
at application level resulting in higher than 64 kbit/s data rates, or it
also allows simultaneous speech and data calls. Multicall was defined as a
supplementary service in Release 99 with limitation of only one CS bearer to be used for speech at any one times. A speech
call is one of TS11 (Telephony), TS12 (Emergency Calls), and TS61 (Alternate
speech/fax).
If the bearer capability information is not
available (e.g. because the call is originated/transited by a PSTN), the basic
service cannot be deduced and the network shall, for Multicall purposes, handle
the call as telephony. A held call shall be regarded as using the bearer
employed when the call was active. With Multicall, it is possible to release
each active CS call independently of any other CS call.
The maximum number of simultaneous CS
bearers available to the subscriber is from 2 to 7, defined as part of the
subscription by “Nbr_SB”.
All of the radio signalling specific to
Multicall is at the served mobile subscriber side, i.e. all other mobiles
involved in the call (and non-mobiles too) see only “basic” call control and
radio signalling, with no special messages or information elements pertaining
to the Multicall service.
The mobile subscriber supporting Multicall
shall include the stream identifier (SI) Information Element (IE). The purpose
of the SI IE is to associate a particular call with a Radio Access Bearer
(RAB), and to identify whether a new traffic channel is requested for the call.
TS 24.008 defines the rules on allocating SIs. MS capability (number of bearers
and number of speech bearers) is included in Call Control IE. And since the MS
shall be aware of the network capabilities, the network indicates its Multicall
capability to the MS by using CC message. When the MS is located in a network
not supporting Multicall, it shall not request multiple bearers.
At inter-MSC
handover, in case just one RAB can be maintained after the handover (e.g. at
handover from UMTS to GSM), MSC-B indicates to MSC-A which RAB has been
selected so that the corresponding call is the only one maintained.
3.6.Open Service Architecture
These
specifications were produced jointly by Parlay, ETSI SPAN (now TISPAN) and 3GPP
WGs SA1 (Stage 1), SA2 (Stage 2) and CN5 (Stage 3), so that there is a single
set of standard OSA APIs for the whole development community.
Open Service Architecture (which became in
later Releases “Open Service Access”) allows service development by operators
and third parties: it enables service application developers to make use of
network functionality through open, standardised, secure, extensible and
scalable interfaces. Applications see the network functionality offered to them
as a set of Service Capability Features (SCFs) in the OSA APIs. These SCFs
provide access to the network capabilities on which the application developers
can rely when designing their applications. The OSA APIs are independent of
where or which network capabilities are implemented in the network, and of
vendor-specific solutions and programming languages.
Two different types of SCFs can be
distinguished:
- Framework
SCF: they provide commonly used utilities, necessary for the non-framework
service capability features to be accessible, secure, resilient and manageable.
The Framework SCFs are:
·
Authentication
·
Authorisation
·
Registration
·
Discovery
·
Notification
- Non-Framework
SCFs: they enable the applications to make use of the functionality of the
underlying network capabilities (e.g. User Location service capability
features). The Non-Framework SCFs are:
·
Session Control
·
Security/Privacy
·
User Location
·
User Status
·
Terminal Capabilities
·
Information Transfer
·
User Profile Management
·
Charging
3.7 . Super Charger
The Super-Charger constitutes a change to
the subscriber data management to reduce mobility management costs associated
with inter-VLR and SGSN location updates, at the cost of increased memory in
the VLR and minor protocol modifications.
Without Super-Charger, the subscriber data
at the old MSC/VLR is deleted when the subscriber moves to a location area
served by a different MSC/VLR.
With Super-Charger, the subscriber data is
maintained in the old MSC/VLR, which removes the need to use the cancel
location procedure, as shown in the figure “Morning Commute in a Super-Charged
Network”. The HLR performs the normal “insert subscriber data” procedure at the
new MSC/VLR. The subscriber data at the old MSC/VLR is not maintained, so no
additional signalling is required.
The network benefits from Super-Charger
when the subscriber roams to a previously visited MSC/VLR where the user’s
subscription data is already present. In this case, provided the subscription
data is still valid, there is no need to perform the “insert subscriber data”
procedure, as shown in the following figure. Consequently, it reduces mobility
management cost by reducing the volume of location update signalling.
Morning and Evening Commutes in a Network using
Super-Charger
Super-Charger is of most benefit in
metropolitan areas where the density of MSC/VLRs is high to cope with the large
number of subscriber, and subscribers regularly commute between location areas
served by different MSC/VLRs. Assuming the subscriber data has not been deleted
or changed since the subscriber was last attached in the location area, then
the MSC/VLR has the option to use the subscriber data previously downloaded.
However, the HLR will ultimately control data retention and updates in the
MSC/VLR.
In a “Super-Charged” network, subscription
data is retained by the previous network entity when the subscriber roams to a
new network entity.
When a subscriber performs location
updating in a Super-Charged network, the HLR shall cancel the subscription
information at the previous network entity only if it does not support the
Super-Charger functionality. If the network entity to which the subscriber has
roamed has retained subscription data from a previous visit, then the HLR shall
only send subscription data to the network entity if the retained subscription
data is not consistent with the data stored by the HLR. If the HLR does not
send subscription data to the serving network entity, it shall treat the
retained subscription data as valid.
To know whether the data maintained in the VLR
is still valid when the subscriber re-enters the Location Area, a new optional
parameter called “ageOfSubscriberData” is added to the “MAP Update Location”
message. This parameter indicates whether the VLR supports the Super-Charger,
and provides the date/time at which the subscription data was last modified in
the HLR. This new optional parameter is also added to the “Insert Subscriber
Data” message to communicate the date/time at which the subscription data was
last modified. Upon receipt of the “ageOfSubscriberData” parameter, the HLR
shall compare the received date/time against the date/time stored against the
subscription data in the HLR and the insert subscriber data procedures is
triggered only if the VLR’s “ageOfSubscriberData” is older than the HLR’s one.
The Super-Charger
concept is equally applicable to packet services. In this case, in the previous
explanations, “VLR” has to be replaced by “SGSN” and “MAP Update Location” has
to be replaced “MAP Update GPRS Location”.
3.8.Follow Me
“Follow Me” (FM) enables an initiating
mobile subscriber A to have control over the Follow Me data of a subscriber B
such that subsequent calls destined to Subscriber B are forwarded to initiating
subscriber A. An initiating subscriber might also be allowed to erase the
Follow Me data of a remote subscriber who has been registered to a different
initiating subscriber for the Follow Me application (this functionality is
called “forced erasure”).
Follow Me is a PLMN specific feature and
the control operations of FM are based on USSD. All messages between the MS and
the mobile network and the ones internal to the mobile network are USSD
messages.
The functionality of forwarding calls for
subscriber B to initiating subscriber A (after successful registration of FM)
is the same as the functionality of the Call Forwarding Unconditional (CFU)
Supplementary Service applied to all telecommunication services of subscriber B
for which CFU is applicable. It can also be achieved by making use of an
equivalent operator specific service (e.g. via CAMEL).
The functionality of the control of Follow
Me (registration, erasure, forced erasure and interrogation) is split between
the HLR of the initiating subscriber A (HLRa) and the Follow me Function Node
(FFN) of the subscriber B (FFNb).
3.9. Synchronisation and Object
exchange
As part of this work item, the concept of
Wide Area Synchronisation for 3GPP has been developed to allow data stored in
the ME/USIM to be synchronised with the outside world.
TR 27.903 provides
information on existing synchronisation protocols. It summarises proprietary
and standard protocols relevant to current and future mobile communication
devices. The document covers only synchronisation between end-user devices,
desktop applications, and server-based information services. It does not refer
to replication or synchronisation between enterprise databases.
After the analysis
done within the above TR, TS 27.103 was created. This specification provides a
definition of a Wide Area Synchronisation protocols. The synchronization
protocol was based upon IrMC level 4. The document covers Wide Area Network
Synchronisation between current and future mobile communication end-user
devices, desktop applications and server-based information servers. It was designed
as a living document and, as such, it will evaluate new technologies (e.g. XML)
for inclusion as they become readily available. (Please note that from Rel-4
onwards the IrMC was removed from 27.103 and replaced by SyncML.)
3.10.Terminal interfaces
3.10.1.AT commands for 3GPP
This work item is about AT commands for control of 3GPP Mobile Equipments (MEs) via an external Terminal
Equipment (TE), fully compatible with GSM AT commands. Several new AT commands
have been added in Release 99 e.g. to control ASCI services.
AT: ATtention; this two character abbreviation is always used to
start a command line to be sent from TE to TA. TE is the Terminal Equipment,
e.g. a computer (equal to DTE ;
Data Terminal Equipment), TA is Terminal Adaptor, e.g. a GSM data card (equal
to DCE; Data Circuit terminating Equipment)
ASCI: Advanced Speech Call Items, including Voice Group Call
Service (VGCS), Voice Broadcast Service (VBS) and Enhanced Multi-Level
Precedence and Pre-emption Service (eMLPP)
TS 27.007 specifies
a profile of AT commands and recommends that this profile be used for
controlling ME functions and GSM network services from a TE through Terminal
Adaptor (TA). The command prefix +C is reserved for Digital Cellular in ITU-T
Recommendation V.25ter. This TS has also the syntax details used to construct
these extended GSM commands. Commands from ITU-T Recommendation V.25ter and
existing digital cellular standards (TIA IS-99 and TIA IS-135) are used
whenever applicable. Some of the new commands are defined such way that they
can be easily applied to ME of networks other than GSM.
3.10.2.Physical interfaces
Under this work item several options for
physical terminal interfaces have been evaluated. Finally, 3GPP concluded that
3GPP should not produce any technical specification for terminal interfaces
other than the radio interface and the USIM interface. The SDOs could develop
their own optional physical connector specification based on their market
requirements.
3.10.3.Multiplexer
This work item is
about a Multiplexing protocol to allow a number of simultaneous sessions over
the terminal interface. TS 27.010 defines a multiplexing protocol between
a mobile station and a terminal. The multiplexing protocol can be used to send
any data, for instance voice, SMS, USSD, fax etc. It describes the protocol,
but not the commands or data transported with it.
3.11.Bearer Services
3.11.1.Circuit Switched Bearer Services
Circuit switched data services and
"real time" data services are provided for interworking with the
PSTN/ISDN so that the user is unaware of the access network used (UMTS and GSM
access network or handover between access networks). Both transparent (constant
delay) and non-transparent (zero error with flow control) services are
supported. These data services are designed to operate with minimum loss of
data on handover between the GSM access network and the UTRAN.
The CS Bearers are applicable for the
support of real-time applications, e.g. Fax and Video and also the GSM General
Bearer Services (GBS) and interworking scenarios as specified in TS 22.002
(R99).
Both Asynchronous and Synchronous access
modes are supported (if applicable) for:
- 3.1kHz Audio modems up to V.90 (0.3kbit/s-56kbit/s)
- V.110 UDI (0.3kbit/s-56kbit/s)
- X.31 flag stuffing UDI (2.4 kbit/s-56kbit/s)
- V.120 (1.2kbit/s-56kbit/s)
- Bit Transparent Mode (56kbit/s and 64kbit/s)
- PIAFS (29.2kbit/s and 58.4kbit/s).
3.11.2.Frame Tunnelling Mode
Frame Tunnelling Mode (FTM) is a generic
term for HDLC (High-level Data Link Control) and HDLC-related transmission
protocols. FTM is a type of the asynchronous non-transparent CS bearer service
(as described in TS 22.002).
3.11.3.Access to ISPs and Intranets – Wireless/Remote
access to LANs
This Work Item introduces the access to an
Intranet or Internet Service Provider (ISP) by running DHCP between the TE and
a server in the Intranet/ISP domain. The corresponding interworking with the
PDN is described in a new clause of TS 29.061.
At PDP context activation, the MS requests
an APN offering the DHCP service. The IP address of the PDP context is
provisionally set to 0.0.0.0 as no IP address is allocated at this moment.
The TE runs a DHCP client, after the PDP
context has been successfully activated, to retrieve the IP address and other
configuration parameters from a DHCP server located in the Intranet/ISP domain.
The PDP context is then updated through the GGSN-initiated modification
procedure to reflect the newly allocated IP address.
A Packet Domain-specific DHCP Relay Agent
is needed in the GGSN to allow for the correct routing of broadcast DHCP
messages.
The PHS Internet Access Forum Specification
(PIAFS) service is one type of CS bearer data service as described in TS
22.002. It refers to an asynchronous circuit switched transmission protocol
over ISDN 64 kbit/s unrestricted digital line. It has the particularity to
be the bearer service provided by the Personal Handy Phone System (PHS) in Japan
3.12.UICC and USIM related features
3.12.1.UICC / Terminal interface; Physical and logical
characteristics
For 3G,
the GSM specification GSM 11.11 has been divided into two parts. The 3G version of GSM 11.11 consists of a "platform"
standard comprised of the basic physical, electrical and logical specification
(TS 31.101) and an application specification (TS 31.102).
This work item covers the definition of a
generic Terminal/Integrated Circuit Card (ICC) interface. This generic platform
is independent of the 3G USIM application and can thus be the platform for any
IC card application. The aim is to ensure interoperability between an ICC and a
terminal independently of the respective manufacturer, card issuer or operator.
Any aspects related to the administrative
management phase of the ICC are not defined under this work item. Any internal
technical realisation of either the ICC or the terminal is only specified where
these are reflected over the interface. Application specific details for
applications residing on an ICC are specified in the respective application
specific documents (e.g. TS 31.102 for the USIM application).
The following aspects are specified:
-
the requirements for the
physical characteristics of the UICC;
-
the electrical interface
between the UICC and the Terminal;
-
the initial communication
establishment and the transport protocols;
-
the model which serves as a
basis for the logical structure of the UICC;
-
the communication commands and
the procedures;
-
the application independent
files and protocols.
Furthermore, general security aspects of IC cards such as file access
conditions are specified. Specific USIM security aspects are dealt with in the
" Characteristics of the USIM application " work item.
The UICC is capable of being used as the
basis for a multi-application card: several USIMs and/or other applications can
co-exist on the card. A new security architecture allows flexible and user-friendly
(i.e. the ability to group PINs together) handling on PINs. For a more
efficient data transfer between the terminal and the IC card, the support for
the ISO/IEC T=1 block transmission protocol was added.
Note that after the
creation of the ETSI Project Smart Card Platform (SCP), 3GPP TSG-T #9 (October
2000) decided to replace the technical
content of TS 31.101 R99 by a reference to ETSI TS 102 221 "Smart
Cards; UICC-Terminal interface; Physical and logical characteristics (Release
1999)". Since then, ETSI EP SCP is
responsible for the generic Terminal/Integrated Circuit Card (ICC)
interface.
3.12.2.Characteristics of the USIM application
For 3G,
the GSM specification GSM 11.11 has been divided into two parts. The 3G version of GSM 11.11 consists of a "platform"
standard comprised of the basic physical, electrical and logical specification
(TS 31.101) and an application specification (TS 31.102).
This work item covers the definition of the
Universal Subscriber Identity Module (USIM) application for 3G telecom network
operation. This application resides on the UICC, an IC card specified in
TS 31.101 (see previous section).
The following aspects are specified:
- specific
command parameters;
- file
structures;
- contents
of EFs (Elementary Files);
- security
functions;
-
application protocol to be used
on the interface between UICC (USIM) and ME.
This is to ensure interoperability between
a USIM and an ME independently of the respective manufacturer, card issuer or
operator.
The work
item does not cover any aspects related to the administrative management phase
of the USIM. Any internal technical realisation of either the USIM or the ME is
only specified where these are reflected over the interface. Also not covered
is the definition of any of the security algorithms which may be used.
For the
phone book, a new concept to handle abbreviated dialling numbers, email address
and other personal data was developed (backwards compatibility issues have been
addressed). New fields were specified to allow easier synchronisation with PCs
or other devices. The grouping of phone numbers was standardised.
New
fields are specified to allow storage of incoming and outgoing call
information.
The
concept of Fixed dialling Numbers (FDN) and Barred Dialling Numbers (BDN) is
far less complex than in GSM. The FDN can also now be applied to particular
APNs for GPRS.
Enhanced security feature were implemented e.g.
new authentication (as specified by SA 3).
3.12.3.UICC Application Identifiers
This work item creates a specification for
the definition and administration of Application IDentifiers (AID) for the
UICC. The numbering system for AIDs for 3G telecommunication Integrated
Circuits (IC) card applications has been defined. The numbering system provides
a means for an application and related services offered by a provider to
identify if a given card contains the elements required by its application and
related services. An AID is used to address an application in the card. It
consists of a Registered application provider IDentifier (RID) and a
Proprietary application Identifier eXtension (PIX). The Specification describes
the coding of the PIX. The coding of the PIX as well as the registration
procedure is described in accordance with ISO/IEC 7816-5.
3.12.4.USIM Application Toolkit
This work item covers the definition of the
interface between the Universal ICC (UICC) and the Mobile Equipment (ME), and
mandatory ME procedures, specifically for "USIM Application Toolkit".
The work was originally based on GSM 11.14 (SIM Application Toolkit). Commands
and procedures are defined in both the USIM and 3G Terminal for using the USIM
Application Toolkit. The requirements are derived from the service and security
requirements defined in 3G TS 22.100 and 22.101.
USAT is a set of commands and procedures
for use during the network operation phase of 3G, in addition to those defined
in TS 31.101. The USAT provides mechanisms which allow applications,
existing in the UICC, to interact and operate with any ME which supports the
specific mechanism(s) required by the application.
Specifying the interface is to ensure
interoperability between a UICC and an ME independently of the respective
manufacturers and operators.
The following aspects are defined:
- the
commands;
- the
application protocol;
-
the mandatory requirements on
the UICC and ME for each procedure.
Examples
of defined functions are (many more exist):
-
displaying text from the UICC
to the ME
-
sending a short message
-
setting up a voice or data call
to a number held by the UICC
-
initiating a dialogue with the
user
-
Data download to UICC
-
Menu selection
3.12.5.Specification of a bearer independent protocol for SAT applications
to exchange data over the GSM network
GSM 11.14 already defines mechanisms for
the exchange of data with servers in the network using SMS and USSD. The
corresponding bearers (SMS and USSD) are suitable as long as very little amount
of data have to be transferred. This work item defines, at the SIM-ME interface,
a basic protocol allowing SIM Toolkit applications to determine available
bearers and to exchange data by selecting using the most appropriate bearer
available (Circuit Switched Data, GPRS, SMS, USSD, etc.).
On the SIM side, the technology now allows
the SIM applications themselves to be downloaded over-the-air. The performance
of SMS or USSD may not be sufficient for this purpose. On the network side, the
required level of performance is available through data calls (CSD and GPRS).
On the ME side, the data capability is available on a large scale.
Therefore, it was decided to boost the
emergence of value added services based on the SIM Application Toolkit using
existing bearers. A mechanism at the interface between the SIM and the ME was
defined which provides access to the data bearers supported by the ME. The main
requirements were:
·
ability for the SIM to use more
performant bearer services, at least for data download;
·
no impact on hardware and
little impact on software for the ME;
·
minimum impact on network.
3.12.6. Specification of administrative commands and functions for IC cards
The specification resulting form this work
item has been developed by SMG9 as part of its mandate to develop generic IC
card specifications and thus had not been allocated a GSM specification number.
It specifies the functions and syntax for a set of administrative commands for
a telecommunication IC Card. Administrative commands are used during the
installation, activation and de-activation of applications. Please note that this
specification was handed over to the ETSI Project Smart Card Platform (SCP) in
2000.
3.12.7.USIM and UICC requirements
This work item
creates a high level description of requirements for the 3GPP IC card and its
interface to the 3GPP terminal. The document created defines requirements of
the USIM (Universal Subscriber Identity Module) and the IC card for 3GPP
(UICC). These are derived from the service and security requirements defined in
3GPP 22.01 and 22.00. The USIM is a 3GPP application on an IC card. It
inter-operates with 3GPP terminals and provides access to 3GPP services. The
document is intended to serve as a basis for the specification of the USIM, the
UICC, and the interface to the 3GPP terminal.
3.13.Security related features
3.13.1.Fraud
Information Gathering Service
This feature provides the means for the
HPLMN to monitor the activities of its subscribers in a VPLMN. The VPLMN
collects information about a defined set of activities on monitored subscribers
and sends this information back to the HPLMN. This enables the HPLMN to perform
service limitation controls such as Operator Determined Barring (ODB) and
Immediate Service Termination (see below), to limit their financial exposure to
subscribers producing large unpaid bills.
Only
Connection-orientated services are covered for Release 99.
3.13.2. Immediate Service Termination
This feature provides the means for the
HPLMN to terminate all the activities of an HPLMN subscriber in a VPLMN. If the
HPLMN decides (based upon information received via FIGS or other systems) that
a roaming subscriber is behaving in a fraudulent or suspicious manner, the
HPLMN can terminate all activities of the subscriber, including calls
(including transferred and diverted calls) that are in progress.
This procedure can also be used to
terminate all the activities of a subscriber when the subscription has ended.
IST implementation is based on two new MAP
messages: MAP_IST_ALERT and MAP_IST_COMMAND, defined in TS 29.002. In
particular, the MAP_IST_COMMAND is used by the HLR to instruct the MSC (Visited
MSC or Gateway MSC) to terminate ongoing call activities for a specific
subscriber.
Note that another implementation, based on
CAMEL, was envisaged but finally not performed in this Release.
Continue to read the : GSM Features, Please Click Here .
0 comments:
Post a Comment
If there is any comments,Please leave a comment at here.