SMSC Change

Specification
UCS2

Change request PM98/xxx

CMG

1998 CMG Telecommunications & Utilities, Division Advanced Technology

1
Version History

Version

Date

Details of Changes

Author(s)

Functional Specification

Eloy Nooren

Approval Record

The information in this document is subject to change without notice and should not be construed as a commitment by CMG. CMG
assumes no responsibility for any errors that may appear in this document.
The software described in this document is furnished under license and may be used or copied only in accordance with the terms of
such license.

Version
1.0

Date

Approved by

Signature

Fevzi akmak

Change request PM98/xxx SMSC Change Specification Version 1.0

Requirement Specification

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2
Table of contents

Requirement Specification.............................................................................1-5
1.1.1 Requirements.................................................................................................................. 1-5

Functional Specification.................................................................................2-6
2.1

General........................................................................................................................... 2-6

2.1.1 License............................................................................................................................ 2-6

2.1.2 Supported and Non-Supported Interworkings.................................................................2-6
2.1.3 SM Submission and Delivery.......................................................................................... 2-6
2.1.4 Short Message Contents................................................................................................. 2-7
2.1.5 Data Coding Scheme...................................................................................................... 2-7
2.1.6 Template Texts................................................................................................................ 2-7
2.1.7 Notifications..................................................................................................................... 2-7
2.1.8 Last Resort Addressing................................................................................................... 2-8
2.1.9 Operator Interface........................................................................................................... 2-8
2.2

PLMN Interworking.......................................................................................................... 2-8

2.2.1 Scan tags........................................................................................................................ 2-8

2.2.2 SM Submission and Delivery........................................................................................2-10
2.2.3 Notifications................................................................................................................... 2-10
2.2.4 Last Resort Addressing................................................................................................. 2-10
2.2.5 Deferred Delivery........................................................................................................... 2-11
2.3

PC Interworking............................................................................................................. 2-11

2.3.1 Supported UCP Operations........................................................................................... 2-11

2.3.2 Notifications................................................................................................................... 2-12
2.3.3 Last Resort Addressing................................................................................................. 2-12
2.4

VMS Interworking.......................................................................................................... 2-12

2.4.1 Supported UCP Operations........................................................................................... 2-12

2.4.2 Notifications................................................................................................................... 2-12
2.5

VSMPP Interworking..................................................................................................... 2-13

2.5.1 SMPP Commands......................................................................................................... 2-13

2.6

Licensed Options........................................................................................................... 2-13

2.6.1 Option 001: Enquiry & Delete........................................................................................2-13

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.6.2 Option 002: Long Messages......................................................................................... 2-13

2.6.3 Option 005: Secondary Addressing...............................................................................2-14
2.6.4 Option 006: Fax Recipient Name...................................................................................2-14
2.6.5 Option 010: Hide Calling Line Identification...................................................................2-14
2.6.6 Option 013: Modify Short Message via UCP.................................................................2-14
2.6.7 Option 041a: Voice Interworking via UCP......................................................................2-14
2.6.8 Option 041b: IVR/Fax Interworking via UCP.................................................................2-15
2.6.9 Option 042: Voice Interworking via SMPP.....................................................................2-15
2.6.10Option 043: X.400......................................................................................................... 2-15
2.6.11Option 044: Fax Delivery............................................................................................... 2-15
2.6.12Option 045: ERMES Delivery........................................................................................2-15
2.6.13Option 046:TAP Submission Interworking.....................................................................2-15
2.6.14Option 047:TAP Delivery Interworking...........................................................................2-15
2.6.15Option: 062: MO/SM Alphanumeric Addresses.............................................................2-15
2.6.16Option 063: Large Account Password Check (CLI and non-CLI Sessions)...................2-16
2.6.17Option 064: Virtual SMSC............................................................................................. 2-16
2.6.18Option 080: Distribution Lists (Mobile Users)................................................................2-16
2.6.19Option 081: Fax Reporting............................................................................................ 2-16
2.6.20Option 082: Subscriber Based Last Resorted Address.................................................2-17
2.6.21Option 083: Subscriber Password Authentication (UCP Users)....................................2-17
2.6.22Option 084: User Group And User Authorisation...........................................................2-17
2.6.23Option 085: Priority Delivery.......................................................................................... 2-17
2.6.24Option 087: GSM Subscriber Access Via Fixed Network..............................................2-18
2.6.25Option 088: Forwarding................................................................................................. 2-18
2.6.26Option 101: Message Based LRAD...............................................................................2-18
2.6.27Option 104: Multi Language Support For MENU Interfaces..........................................2-19

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

Preface

UCS2
The GSM 3.38 Alphabets and Language-Specific Information document specifies
that an SMSC should be able to receive and deliver SM-s encoded in UCS2. UCS2
is a 16-bit character set that covers all characters of all alphabets existing in the
world. Hence, it does not only contain the Latin characters, but also characters of
exotic alphabets like Greek, Hebrew, Arabic, Chinese, Tamil, Thai, etc.
Details about UCS2 are specified in the ISO/IEC1046 Universal Multiple-Octet
Coded Characters Set (UCS) document.
At the moment, CMGs range of customers is expanding to operators of countries
that do not commonly use the Latin alphabets, e.g. Israel, Arabian countries,
China, Thailand, etc. In order to serve the needs of these operators properly, the
SMSC has to support UCS2.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

3
1

Requirement Specification

1.1.1 Requirements
The SMSC should be capable of:

receiving UCS2 encoded SM-s from MS-s

delivering UCS2 encoded SM-s to MS-s

receiving UCS2 encoded SM-s from PC users

delivering UCS2 encoded SM-s to PC users

receiving UCS2 encoded VMN-s from Voice Mail Systems

Furthermore, the SMSC should support UCS2 for the following parts of
functionality:

notifications

inquiry & delete

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

4
2

Functional Specification

2.1 General
2.1.1 License
The UCS2 functionality is part of the SMS Phase 2 license.
2.1.2 Supported and Non-Supported Interworkings
The table below shows all interworkings and an indication of their ability to support
UCS2.

Interworking

UCS2 Support
for Submission

UCS2 Support
for Delivery

PLMN

Yes

Yes

PC

Yes

Yes

MENU

No

No

TAP

No

No

ERMES

Not applicable

No

FAX

Not applicable

No

VMS

Yes

Not applicable

VSMPP

Yes

Not applicable

DTMF

No

Not applicable

IVR

No

Not applicable

X.400

No

Not applicable

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.1.3 SM Submission and Delivery

Whenever an SM is submitted, the SMSC determines which interworking should be
used to deliver the SM. Not every interworking supports UCS2. Therefore, as a
rule, the SMSC rejects any UCS2 encoded SM that is undeliverable due to lack of
UCS2 support of the delivery interworking.
Remarks:

The rule as it just has been presented does not apply for SM-s sent to
distribution lists. Refer to 2.6.18 for details regarding SM-s to distribution lists.

In case an SM is associated with a last resort address, a more sophisticated

strategy applies. Refer to 2.1.8 for details regarding this strategy.

In case the recipient of an SM has configured forwarding, the strategy is

different as well. Refer to 2.6.25 for details regarding this strategy.

2.1.4 Short Message Contents

The following applies to the contents of UCS2 encoded SM-s:

The maximum number of UCS2 characters in an SM is 70.

The SMSC passes UCS2 encoded SM-s transparently from originator to

recipient. Thus, the SMSC does not apply any character conversion upon
receipt or delivery of UCS2 encoded SM-s.

2.1.5 Data Coding Scheme

The following applies for the data coding scheme of UCS2 encoded SM-s:

Coding group is general data coding

No text compression

Message class has to be specified

All of the message classes are supported

The alphabet should be set to UCS2

The above is according to the data coding scheme specification as described in the
GSM 3.38 Alphabets and Language-Specific Information document.
2.1.6 Template Texts
The SMSC provides a means for the operator to customise the text within
notifications, inquiry responses, and delete responses. In order to do so, the
operator has to adapt some text templates.
It is only possible to change the text templates in a language that uses characters
of the default GSM alphabet. The SMSC provides no means to specify the text
templates in an UCS2-specific alphabet.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.1.7 Notifications
Basically, the SMSC provides two notifications mechanisms: These mechanisms
are:

Notifications based on texts

The SMSC provides a means to the operator to customise the notifications
texts. Encoding the notification texts in UCS2 is not possible. Hence, using the
notification texts in an UCS2-oriented SMSC might be considered as
inappropriate (e.g. A person submitting an SM in Chinese might be surprised,
or even annoyed, when he receives a notification in English.)

Notifications based on status indicators

The philosophy of this mechanism is that the SMSC passes some status
indicators to the SME. Based on these indicators, the SME will select one of its
pre-formatted notification texts and present it to the end-user.

When using notifications in an UCS2-oriented SMSC, the only appropriate

notification mechanism is the one based on status indicators. However, this
notification mechanism requires additional functionality in the SME, and
unfortunately, this functionality is not always present (e.g. phase 1 MS-s).
2.1.8 Last Resort Addressing
The SMSC provides a means to associate a last resort address with an SM.
Associating can be done in two ways:

explicitly by requesting for a last resort address when submitting the SM

implicitly by sending an SM to a recipient for which a last resort address has

been defined in the subscriber database

In case an SME sends an SM that is explicitly associated with a last resort

address, the SME is fully aware of the last resort addressing mechanism. The SME
requested for it, and hence expects that the SMSC will deliver the SM at the last
resort address when SM delivery to the recipient has failed. Therefore, the SMSC
will reject any UCS2 encoded SM that cannot be delivered at the last resort
address due to lack of UCS2 support of the delivery interworking. Note that the SM
is rejected at the time that the SMSC receives the SM and not at the time that the
SMSC starts the last resort addressing mechanism.
In case an SME sends an SM that is implicitly associated with a last resort
address, the SME is not aware of the last resort addressing mechanism. The SME
did not request for it, and hence, will be very surprised, or even annoyed, when an
UCS2 encoded SM is rejected due to lack of UCS2 support of the delivery
interworking for the last resort address. Therefore, the SMSC will use another
strategy. This strategy comprises the following:

When the SM is submitted, the SMSC accepts it.

When the SMSC cannot deliver the SM at its destination, the last resort
address mechanism will be applied. When the interworking that the SMSC

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

uses to deliver the SM at the last resort address does not support UCS2, it will
reject the SM.
Note that the strategy just presented ensures a proper working of the notification
functionality.
2.1.9 Operator Interface
The operator interface of the SMSC is in English and cannot be customised to
support any another language.

2.2 PLMN Interworking

2.2.1 Scan tags
Scan tags in UCS2 encoded MO/SM are not supported. This restricts functionality.
The table below enumerates all functionality that is restricted or impossible with
UCS2 encoded MO/SM due to the fact that scan tags are not supported.

Functionality

Related Scan Function(s)

For details, refer

to section:

Modification of PID

MOD_PID_TO_ERMES

2.2.2

MOD_PID_TO_FAX
MOD_PID_TO_MENU
MOD_PID_TO_PC
MOD_PID_TO_TAP
MOD_PID_TO_X25PC
MOD_PID_TO_X400
Deferred Delivery

DEFERRED_DELIVERY

2.2.5

Notifications

NOTIF_TO_FAX3

2.2.3

NOTIF_TO_MOBILE
NONOTIF_TO_MOBILE
Last Resort Addressing

LRAD_TO_FAX3

2.2.4

LRAD_TO_PC

2.6.26

LRAD_TO_X400
SET_LRAD_TO_FAX3
Inquiry & Delete

DELETE

2.6.1

INQUIRY
Long Messages

LONG_MESSAGE

2.6.2

LAST_MESSAGE

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

Secondary Addressing

MOD_PID_TO_X25PC

2.6.3

Fax Recipient Name

<TBD>

2.6.4

Hide Calling Line Identification

HIDE_CLI

2.6.5

X.400

GET_X400_SN

2.6.10

Alphanumeric Addressing

ALPHANUM_ADDRESS

2.6.15

Distribution Lists

DISTR_LIST_ADD

2.6.18

DISTR_LIST_REMOVE
DISTR_LIST_SHOW
Fax Reporting

FAX_REPORT_ACTIVATE

2.6.19

FAX_REPORT_DEACTIVATE
FAX_REPORT_SHOW
Priority Delivery

PRIORITY

2.6.23

Forwarding

DISABLE_FORWARDING

2.6.25

ENABLE_FORWARDING
RETRIEVE_FORWARDING
SET_FORWARDING

2.2.2 SM Submission and Delivery

The SMSC supports submission of UCS2 encoded MO/SM-s as well as delivery of
UCS2 encoded MT/SM-s.
Each SM contains a PID. The SMSC uses the PID to determine which interworking
will be used for the delivery of the SM. The PLMN interworking provides some
mechanisms to change the PID. The table below summarises these mechanisms
and an indication whether the SMSC supports them for UCS2 encoded SM-s.

Mechanism

Support for UCS2

encoded SM-s

Scan Tags

No

Address-To-PID Table

Yes

Forwarding

Yes

Last Resort Addressing

NRT Ranges

Yes

VSMSC

Yes

Note that:

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

The mechanisms might result is UCS2 encoded SM-s being rejected due to
lack of UCS2 support of the delivery interworking.

The SMSC also uses the NRT Ranges mechanism to recognise a recipient as
a distribution list. For details regarding distribution lists and UCS2 encoded SMs, refer to 2.6.18.

2.2.3 Notifications
The SMSC has two mechanisms for notification: one based on notification texts,
the other based on status indicators. In 2.1.7, it has been discussed that, for an
UCS2-oriented SMSC, the mechanism for notifications based on status indicator is
the only appropriate one.
The notification mechanism based on status indicators uses the phase 2 feature
called Status Report. Hence, this notification mechanism does not support phase 1
MS-s.
Note that the phase 2 Status Reports feature is not based on scan tags. Hence,
lack of UCS2 support for scan tags does not affect the functionality of this feature.
2.2.4 Last Resort Addressing
Two ways of associating a last resort addressing with an SM exist: explicitly and
implicitly (refer to: 2.1.8).
The SMSC uses scan tags for the explicit way of associating. As the SMSC does
not support scan tags for UCS2 encoded MO/SM-s, it neither supports the explicit
way of associating. However, the implicit way of associating is possible for UCS2
encoded MO/SM-s.
2.2.5 Deferred Delivery
MS-s can only request for deferred delivery by the scan-tag mechanism. Hence, as
scan tags are not supported for encoded UCS2 MO/MS, deferred delivery is not
possible with MO/SM-s encoded with UCS2.

2.3 PC Interworking
2.3.1 Supported UCP Operations
The 50 series of UCP partially supports UCS2. The table below summarises the
extent of UCS2 support for each of the UCP operations of the 50-series.

UCP operation

Extent of
UCS2
Support

51

Submit SM

Fully

52

Deliver SM

Fully

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

53

Deliver Notification

Partially

54

Modify SM

Fully

55

Inquiry SM

Fully

56

Delete SM

Fully

57

Response Inquiry SM

Partially

58

Response Delete SM

Partially

The SMSC only partially supports the Deliver Notification, Response Inquiry SM
and Response Delete SM operations. The SMSC is not able to encode the text field
of these operations in UCS2 format. This stems from the fact that the SMSC does
not provide the operator with an operator interface that supports UCS2.

Implementation Note
The UCP specification document does not yet enable submitting, modifying or delivering UCS2 encoded
SM-s. It needs to be extended. A possible way to do so is:

Allocate one of the reserved fields for the coding group with following values:

Value

Coding Group

00

General Data Coding without compression and with the message class specified

0F

Data Coding / Message Class

Remarks:
-

Only the values mentioned are valid

When no value is specified, Data Coding / Message Class is assumed.

In case Coding Group is set to 00 (General Data Coding without compression and with the message
class specified), the range of values for the DCS field should include the value for the UCS2
alphabet, just as specified by GSM 03.38.

The range of values for MT should be extended with a value for UCS2 encoded SM-s.

A field similar to NMsg, Amsg, and TMsg should be introduced for UCS encoded SM-s. The
maximum length of this field should be 140 octets. (Note that the field TMsg is not used. This field is
related to 8-bit transparant data. For UCS2 data, a separate field is recommended.)

2.3.2 Notifications
UCP Operation 53 Deliver Notification contains redundant information: The type of
notification can be deducted from the notification text as well as from status
indicators.
The SMSC is not capable to encode the notification text in UCS2. Therefore, it is
recommended to use the status indicators when retrieving the type of notification

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.3.3 Last Resort Addressing

Two ways of associating a last resort addressing with an SM exist: explicitly and
implicitly (refer to: 2.1.8). The PC interworking supports both ways of associating.
Refer to 2.1.8 for the strategy of handling UCS2 encoded SM-s that are associated
with a last resort address.

2.4 VMS Interworking

2.4.1 Supported UCP Operations
The operations of the UCP 40 series implement the interface between a VMS and
the SMSC. The table below summarises these operations and their UCS2 support.

UCP operation

Extent of
UCS2
Support

40

Alert MS

Fully

41

Delete SM

Fully

42

VMS Notification

Fully

43

Alert VMS

Fully

Implementation Note
Currently, operation 40 Alert MS does not yet provide a means to specify the type of encoding. Therefore,
one of the following solutions should be chosen:

Extend the UCP protocol

-

Change operation 40 Alert MS in such a way that it can indicate the type of encoding. Note that
this should be done in such a way that backward compatibility is ensured.

Define a new operation (e.g. 44) for the purpose of alerting an MS with a UCS2 formatted text.

On the SMSC, configure the type of encoding for each VMS. This assumes that a VMS submits
either all its alerts in the normal alphabet or all its alerts in UCS2.

2.4.2 Notifications
UCP Operation 42 VMS Notification contains status indicators that reflect the type
of notification. This is the recommended type of notification for UCS2.

2.5 VSMPP Interworking

2.5.1 SMPP Commands
The table below summarises the SMPP commands that the SMSC supports as
well as the UCS2 support of these commands.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

SMPP command

Extent of
UCS2
Support

bind_transmitter

Fully

submit_sm

Fully

cancel_sm

Fully

Implementation Note
The current implementation of the VSMPP interworking does not yet interpret the DCS field of the
submit_sm command. This should be changed in order to support UCS2.

2.6 Licensed Options

This chapter discusses the impact on the licensed options for support of UCS2.
Only licensed options that are affected by UCS2 will be discussed. Options that are
not affected by UCS2 will work as they did before.
2.6.1 Option 001: Enquiry & Delete
This option partially supports UCS2.
This option is related to MS-s and to UCP users.
MS-s
For MS-s, this option is based on scan tags in MO/SM-s. As scan tags are not
supported in UCS2 encoded SM-s, MS-s cannot use UCS2 encoded SM-s to
enquire the status of previously sent SM-s, nor can they delete them.
Note, however, that any SM, regardless of its encoding, can be enquired or deleted
with:

An enquiry/delete scan tag in an MO/SM that is encoded in the conventional

way

An SMS phase 2 enquiry/delete command (option 007)

UCP users
For UCP users, this option is based on two UCP operations from the 50-range. The
SMSC supports UCS2 for requesting enquiry and delete of a previously submitted
SM. However, the enquiry and delete responses of the SMSC are not UCS2
encoded. Refer to 2.1.6 and 2.3.1 for details.
2.6.2 Option 002: Long Messages
This option does not support UCS2.
This option is related to MO traffic and MT traffic.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

MO traffic
For MO traffic, this option is based on scan tags. As scan tags are not supported in
UCS2 encoded SM-s, MS-s cannot send long messages encoded in UCS2.
MT traffic
In order to deliver an MT long message, the SMSC has to split up the long
messages in multiple segments. Each segment should be sent to the MS using an
MT/SM. In the MT/SM, a scan tag and, optionally, a sequence number should
precede the text of the segment. However, as implementation of this is not possible
in case of UCS2 encoding, delivering UCS2 encoded long messages to MS-s is not
possible, and hence, any attempt to submit a MT long message is rejected.
2.6.3 Option 005: Secondary Addressing
This option does not support UCS2.
This option is related to MO/SM-s only.
MO/SM-s
This option is based on scan tags. As scan tags are not supported in UCS2
encoded SM-s, MS-s cannot specify a secondary address in an MO/SM encoded
in UCS2.
2.6.4 Option 006: Fax Recipient Name
This option does not support UCS2.
This option is related to MO/SM-s only.
MO/SM-s
This option is based on scan tags. As scan tags are not supported in UCS2
encoded SM-s, MS-s cannot specify a fax recipient name in a MO/SM encoded in
UCS2. Besides that, the option requires fax interworking, and this is not supported
for UCS2 either.
2.6.5 Option 010: Hide Calling Line Identification
This option does not support UCS2.
This option is related to MO/SM-s only.
MO/SM-s
This option is based on scan tags. As scan tags are not supported in UCS2
encoded SM-s, MS-s cannot request for hiding the CLI in an MO/SM encoded in
UCS2.
2.6.6 Option 013: Modify Short Message via UCP
This option fully supports UCS2. Refer to section 2.3.1 for details.
SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.6.7 Option 041a: Voice Interworking via UCP

This option fully supports UCS2. Refer to section 2.4 for details.
2.6.8 Option 041b: IVR/Fax Interworking via UCP
UCS2 is not supported for the IVR interworking. Hence, this option does not
support UCS2.
2.6.9 Option 042: Voice Interworking via SMPP
This option fully supports UCS2. Refer to section 2.5 for details.
2.6.10Option 043: X.400
UCS2 is not supported for the X.400 interworking. Hence, this option does not
support UCS2.
The SMSC rejects any attempt to submit MO/SM with an X.400 user as
destination.
2.6.11Option 044: Fax Delivery
UCS2 is not supported for the Fax interworking. Hence, this option does not
support UCS2.
The SMSC rejects any attempt to submit MO/SM with a FAX user as destination.
2.6.12Option 045: ERMES Delivery
UCS2 is not supported for the ERMES interworking. Hence, this option does not
support UCS2.
The SMSC rejects any attempt to submit MO/SM with an ERMES user as
destination.
2.6.13Option 046:TAP Submission Interworking
UCS2 is not supported for the TAP interworking. Hence, this option does not
support UCS2.
2.6.14Option 047:TAP Delivery Interworking
UCS2 is not supported for the TAP interworking. Hence, this option does not
support UCS2.
The SMSC rejects any attempt to submit MO/SM with a TAP user as destination.
2.6.15Option: 062: MO/SM Alphanumeric Addresses
This option partially supports UCS2.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

This option consists of three parts of functionality:

Scan tags
Scan tags can be used to specify an alphanumeric address of an LA. As scan tags
are not supported in UCS2 encoded SM-s, MS-s cannot request for alphanumeric
addressing encoded in UCS2.
Phase 2 MS-s
Some phase 2 MS-s provide the possibility to specify the destination in
alphanumeric format. This is supported for UCS2 encoded SM-s. Note, however,
that although the SM contents is UC2 encoded, the destination itself is not UCS2
encoded.
Subaddressing
This functionality is related to the Scan Tags functionality. The Scan Tags
functionality is not supported for UCS2. Hence, UCS2 is neither supported for this
functionality.
2.6.16Option 063: Large Account Password Check (CLI and non-CLI Sessions)
This option fully supports UCS2.
Note, however, that passwords cannot be encoded in UCS2.
2.6.17Option 064: Virtual SMSC
This option fully supports UCS2.
Note, however, that passwords cannot be encoded in UCS2.
2.6.18Option 080: Distribution Lists (Mobile Users)
This option partially supports UCS2.
This option consists of two parts of functionality:
Submitting MO/SM to distribution list
Distribution lists consist of four types of users: MS-s, PC users, MENU users, and
FAX users. MENU en FAX interworkings do not support UCS2. Hence, UCS2
encoded SM-s cannot be delivered to any MENU or FAX member of a distribution
list.
The strategy for submitting an UCS2 encoded SM to a distribution list is as follows:

When the SM is submitted, the SMSC accepts it.

The SMSC will attempt to deliver the SM to any member of the distribution list.
The PLMN and PC delivery interworkings will actually try to deliver the SM-s.
The MENU and FAX delivery interworkings will reject the SM immediately due
to lack of UCS2 support.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

Note that the strategy just presented ensures a proper working of the notification
functionality.
Distribution list provisioning
Provision of distribution lists can be done in two ways:

by the operator using PRX or PRL

by the MS using scan tags.

As scan tags are not supported in UCS2 encoded SM-s, MS-s cannot do provision
distribution lists with an UCS2 encoded SM.
2.6.19Option 081: Fax Reporting
This option partially supports UCS2.
This option consists of two parts of functionality:
Generating fax report
When UCS2 encoded SM-s are used, fax reports can be generated. However, fax
reports cannot be generated in UCS2 format as fax interworking does not support
UCS2
Provisioning of fax report settings
Provision of fax report settings can be done in two ways:

by the operator using PRX or PRL

by the MS using scan tags.

As scan tags are not supported in UCS2 encoded SM-s, MS-s cannot do provision
fax report settings with an UCS2 encoded SM.
2.6.20Option 082: Subscriber Based Last Resorted Address
This option does not support UCS2. This option uses the fax interworking, and fax
interworking does not support UCS2.
2.6.21Option 083: Subscriber Password Authentication (UCP Users)
This option is fully supported for UCS2.
Note, however, that passwords cannot be encoded in UCS2.
2.6.22Option 084: User Group And User Authorisation
This option is fully supported for UCS2.
Note, however, that passwords cannot be encoded in UCS2.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

2.6.23Option 085: Priority Delivery

This option partially supports UCS2.
This option consists of two parts of functionality:
Submitting an SM with priority
The priority setting of an MS determines whether an MS is able to send a UCS2
encoded SM. Three priority settings are defined. These settings are:

priority off

priority on request

priority always

When the priority setting of the MS is set to priority always, MS-s are able to
submit UCS2 encoded SM-s with priority.
If the priority setting is set to priority on request, an MS should request for priority
by using a scan tag. As scan tags are not supported for UCS2, MS-s have no
means to request for priority for UCS2 encoded SM-s and a priority setting of
priority on request.
Provisioning of priority settings
Provision of priority settings can be done in two ways:

by the operator using PRX or PRL

by the MS using scan tags.

As scan tags are not supported in UCS2 encoded SM-s, MS-s cannot do provision
priority settings with an UCS2 encoded SM.
2.6.24Option 087: GSM Subscriber Access Via Fixed Network
This option fully supports UCS2.
Note, however, that passwords cannot be encoded in UCS2.
2.6.25Option 088: Forwarding
This option partially supports UCS2.
This option consists of two parts of functionality:
Submitting an SM to a forwarded recipient
MS-s have the option to configure forwarding. Forwarding can be configured as
summarised in the table below.

Way of
forwarding

First delivery attempt at

SMSC Change Specification Change request PM98/xxx

Version 1.0

Subsequent attempts at

Requirement Specification

None

specified MS

specified MS

Conditional

specified MS

forwarding address of specified MS

Switched
conditional

forwarding address of specified MS

specified destination

Unconditional

forwarding address of specified MS

forwarding address of specified MS

In case the delivery interworking that is used for a forwarding address does not
support UCS2, the following applies:

The SMSC rejects any UCS2 encoded SM for which the recipient is
unconditionally forwarded.

In case of conditional or switched conditional forwarding, the SMSC does not

attempt to deliver an UCS2 encoded SM at the forwarding address. All
attempts are directed to the MS, as if forwarding had not been configured.

Provisioning of forwarding settings

Provision of forwarding settings can be done in two ways:

by the operator using PRX or PRL

by the MS using scan tags.

As scan tags are not supported in UCS2 encoded SM-s, MS-s cannot do provision
forwarding settings with an UCS2 encoded SM.
2.6.26Option 101: Message Based LRAD
This option partially supports UCS2.
Delivering to a message-based LRAD
Refer to 2.1.8.
Requesting for a message-based LRAD
Message based LRAD can be requested by

MS-s

PC users

MENU users

MENU and PC users are able to specify a message based LRAD for UCS2
encoded SM-s. However, MS-s are not as a message based LRAD should be
specified using a scan tag. Hence, message based LRAD is not supported for
MO/SM-s.
2.6.27Option 104: Multi Language Support For MENU Interfaces
This option does not support UCS2.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification

As only the Latin alphabet is supported, The MENU interfaces cannot be

customized for languages that use characters of UCS2-specific alphabets.

SMSC Change Specification Change request PM98/xxx

Version 1.0

Requirement Specification