ETSI ETS 300 917 ed.1 (1998-05)

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D±$SOLNDFLMVNLSURJUDPVNL
YPHVQLN]D*60*60$3,*60UD]OLþLFD
Digital cellular telecommunications system (Phase 2+) (GSM); GSM Application
Programming Interface (GSM-API) (GSM 07.08 version 5.2.1)
Ta slovenski standard je istoveten z: ETS 300 917 Edition 1
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 917
TELECOMMUNICATION May 1998
STANDARD
Source: SMG Reference: DE/SMG-040708Q
ICS: 33.020
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
Digital cellular telecommunications system (Phase 2+);
GSM Application Programming Interface (GSM-API)
(GSM 07.08 version 5.2.1)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Internet: secretariat@etsi.fr - http://www.etsi.fr - http://www.etsi.org
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1998. All rights reserved.

Page 2
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
Contents
Foreword .7
Introduction.7
1 Scope .9
2 Normative references.9
3 Definitions and abbreviations .11
3.1 Definitions .11
3.2 Abbreviations .11
4 Profile A compatible part of GSM-API.11
5 Profile B compatible part of GSM-API.12
5.1 Overview .12
5.2 Parameter description.12
5.2.1 Additional Info.13
5.2.2 B Channel Information.13
5.2.3 B Protocol.14
5.2.4 B1 Protocol.14
5.2.5 B2 Protocol.15
5.2.6 B3 Protocol.15
5.2.7 B1 Configuration.16
5.2.8 B2 Configuration.16
5.2.9 B3 Configuration.16
5.2.10 BC .17
5.2.11 Called Party Number .17
5.2.12 Called Party Subaddress.18
5.2.13 Calling Party Number .18
5.2.14 Calling Party Subaddress.18
5.2.15 CIP Value .19
5.2.16 CIP mask.22
5.2.17 Connected Number .23
5.2.18 Connected Subaddress.23
5.2.19 Controller.24
5.2.20 Data.25
5.2.21 Data Length.25
5.2.22 Data Handle .25
5.2.23 Facility Selector .25
5.2.24 Facility Request Parameter .26
5.2.25 Facility Confirmation Parameter.26
5.2.26 Facility Indication Parameter .27
5.2.27 Facility Response Parameter .27
5.2.28 Flags.27
5.2.29 HLC .28
5.2.30 Info .28
5.2.31 Info Element .30
5.2.32 Info Mask.30
5.2.33 Info Number.31
5.2.34 LLC.32
5.2.35 Manu ID.32
5.2.36 Manufacturer Specific.32
5.2.37 NCCI.33
5.2.38 NCPI.34
5.2.39 PLCI .35
5.2.40 Reason .35

Page 4
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
5.2.41 Reason_B3 . 36
5.2.42 Reject. 37
6 GSM specific part of GSM-API (addition to ETS 300 838profile A). 37
7 GSM specific part of GSM-API (addition to ETS 300 838profile B). 38
7.1 Overview . 38
7.2 GSM specific functionality . 38
7.3 Extension mechanism. 38
7.4 Registration of GSM support. 39
7.4.1 Register GSM support facility message parameter. 39
7.5 Support of GSM Tele and Bearer Services. 40
7.5.1 Emergency Calls. 40
7.6 Basic GSM functions. 40
7.6.1 Facility message parameter. 41
7.6.1.1 Send Short Messages. 41
7.6.1.2 Receive Short Message. 42
7.6.1.3 Receive Cell Broadcast Messages . 44
7.6.1.4 In Call Modification. 44
7.6.1.5 Read SIM Data. 45
7.6.1.6 Update SIM Data. 47
7.6.1.7 Invalidate SIM file. 48
7.6.1.8 Rehabilitate SIM file . 48
7.6.1.9 Get SIM File Status. 49
7.6.1.10 Handle PIN code. 50
7.6.1.11 Get available PLMNs . 51
7.6.1.12 Set PLMN Mode. 52
7.7 GSM Supplementary Service functions. 52
7.7.1 Overview. 52
7.7.2 Enable GSM Supplementary Service Functionality . 53
7.7.3 GSM Supplementary Services Parameters. 53
7.7.3.1 ss_operation. 53
7.7.3.2 Forwarding Feature. 54
7.7.4 Facility message parameter. 54
7.7.4.1 Restrict SS Information. 54
7.7.4.2 Mobile Originated SS Transaction . 55
7.7.4.3 Clear Mobile Originated SS Transaction. 56
7.7.4.4 Receive SS Message. 57
7.7.4.5 Call Hold. 57
7.7.4.6 Call Retrieve. 58
7.7.4.7 Call Related Ussd . 58
7.7.4.8 Receive Call Related Facility. 59
7.8 Extended GSM functionality . 59
7.8.1 Facility Message parameter. 60
7.8.1.1 Get Service State. 60
7.8.1.2 RX Level and RX Quality . 60
7.8.1.3 Get SIM Present Info . 61
Annex A (informative): GSM Supplementary Services Message flow. 62
A.1 Restrict SS information. 62
A.2 Mobile Originated SS transaction . 62
A.3 Receive SS Message (Forward Check Indication) . 62
A.4 Mobile originated USSD . 63
A.5 Mobile terminated USSD . 63
A.6 Call related USSD. 63
A.7 Call hold. 64

Page 5
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
A.8 Receiving a Call related Facility .64
Annex B (informative): Change history .65
History.66

Page 6
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
Blank page
Page 7
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
Foreword
This European Telecommunication Standard (ETS) has been produced by the Special Mobile Group
(SMG) of the European Telecommunications Standards Institute (ETSI).
This ETS defines GSM-API, the application programming interface within the digital cellular
telecommunications system.
The contents of this ETS may be subject to continuing work within SMG and may change following formal
SMG approval. Should SMG modify the contents of this ETS, it will be submitted for OAP by ETSI with an
identifying change of release date and an increase in version number as follows:
Version 5.x.y
where:
y the third digit is incremented when editorial only changes have been incorporated in the
specification;
x the second digit is incremented for all other types of changes, i.e. technical enhancements,
corrections, updates, etc.
Introduction
This ETS defines GSM Application Programming Interface (GSM-API), the Application Programming
Interface as an extension to ETS 300 838 (HPCI).
GSM-API can be used by PCI applications without any modification. The same existing applications can
be used to transfer data inside GSM networks as well as between GSM networks and ISDNs. Thus it
unifies access to digital networks from application’s point of view.
GSM-API enables applications to access GSM interfaces like mobiles, adapter boards, handhelds, etc. in
a straightforward manner and allows unrestricted use of their functions through a standardized software
interface.
Applications which use this interface will not be affected by future expansions or hardware changes.
GSM-API makes the changes transparent to applications using it. Future expansions that retain
compatibility with existing software base are possible.
GSM-API provides an abstraction of GSM services and features that is independent from the network
provider and from the interfaces used to connect to the network. It provides an easy-to-use interface for
applications and offers a unique access to the different GSM services and features like data transfer, fax,
voice, modem, short message service, SIM access, etc.
GSM-API provides the base for modular applications development in GSM network systems.
Transposition dates
Date of adoption of this ETS: 1 May 1998
Date of latest announcement of this ETS (doa): 31 August 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 28 February 1999
Date of withdrawal of any conflicting National Standard (dow): 28 February 1999

Page 8
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
Blank page
Page 9
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
1 Scope
This European Telecommunication Standard (ETS) defines the GSM Application Programming Interface
(GSM-API) in two parts.
The first part describes, how compatibility to existing application interface ETS 300 838 [14] is covered for
the GSM network. So existing PCI applications are able to be used in a GSM environment. For these
applications the necessary mapping and local knowledge between application interface and network is
described. The only modifications needed in ETS 300 838 [14] to fulfil this requirements are covered by
changes of the parameter description. These changes of parameters are defined in clauses 4 and 5 of
this ETS.
An application compliant with this ETS shall not imply compliance with ETS 300 838 (HPCI).
Clause 4 is meant to replace subclause 5.7 message parameters of ETS 300 838 [14]. which defines the
parameters of the profile A of the HPCI.
NOTE 1: Clause 4is for further study.
Clause 5 replaces subclause 6.8 parameter description of ETS 300 838, which defines the parameters of
the profile B of the HPCI.
The second part defines GSM specific features. New GSM-API applications need extensions to ETS 300
838 [14] which are defined in section 6 and 7of this ETS.
These sections are meant as an addition to ETS 300 838 [14]. They do not replace any clause of ETS 300
838 [14].
Clause 6 defines the extensions according to the profile A of ETS 300 838 [14].
NOTE 2: Clause 6 is for further study.
Clause 7 defines the extensions according to the profile B of ETS 300 838 [14] (bit compatible to
COMMON ISDN API).
The messages and the operating system dependent part of ETS 300 838 [14] will not be changed for
GSM-API.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references, the
latest edition of the publication referred to applies.
[1] GSM 01.04 (ETR 350): "Digital cellular telecommunications system (Phase 2+);
Abbreviations and acronyms".
[2] GSM 02.04 (ETS 300 918): "Digital cellular telecommunications system
(Phase 2+); General on supplementary services".
[3] GSM 02.30 (ETS 300 907): "Digital cellular telecommunications system
(Phase 2+); Man-Machine Interface (MMI) of the Mobile Station (MS)".
[4] GSM 03.38 (ETS 300 900): "Digital cellular telecommunications system
(Phase 2+); Alphabets and language-specific information".
[5] GSM 03.40 (ETS 300 901): "Digital cellular telecommunications system
(Phase 2+); Technical realization of the Short Message Service (SMS) Point to
Point (PP)".
[6] GSM 03.41 (ETS 300 902): "Digital cellular telecommunications system
(Phase 2+); Technical realization of Short Message Service Cell Broadcast
(SMSCB)".
Page 10
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
[7] GSM 04.08 (ETS 300 940): "Digital cellular telecommunications system
(Phase 2+); Mobile radio interface layer 3 specification".
[8] GSM 04.11 (ETS 300 942): "Digital cellular telecommunications system
(Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on
mobile radio interface".
[9] GSM 04.80 (ETS 300 950): "Digital cellular telecommunications system
(Phase 2+); Mobile radio interface layer 3 supplementary services specification
Formats and coding".
[10] GSM 04.90 (ETS 300 957): "Digital cellular telecommunications system;
Unstructured supplementary services operation - Stage 3".
[11] GSM 05.08 (ETS 300 911): "Digital cellular telecommunications system
(Phase 2+); Radiosubsystem link control".
[12] GSM 09.02 (ETS 300 974): "Digital cellular telecommunications system
(Phase 2+); Mobile Application Part (MAP) specification".
[13] GSM 11.11 (ETS 300 977): "Digital cellular telecommunications system
(Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment
(SIM - ME) interface".
[14] ETS 300 383 (1997): "Integrated Services Digital Network (ISDN); Harmonized
Programmable Communication Interface (HPCI) for ISDN".
[15] ETS 300-102-1 (1990): "Integrated Services Digital Network (ISDN),
Usernetwork interface layer 3, Specifications for basic call control".
[16] ITU-T Recommendation Q931 (1993): "Digital subscriber Signalling System No.
one (DSS1) - ISDN user network interface layer 3 specification for basic call
control".
[17] ISO 7776 (1986): "Information Processing systems; Data communications;
High-level data link control procedures: Description of the X.25 LAPD
compatible DTE data link procedures".
[18] IBM publication: "IBM Synchronous Data Link Control Concepts" (GA27-3093).
[19] ITU-T Recommendation Q921 (1993): "ISDN user network interface - Data link
layer specification".
[20] ITU-T Recommendation T.30 (1993): "Procedures for document facsimile
transmission in the general switched telephone Network".
[21] Request For Comment (RFC) 1661: "The Point-to-Point Protocol (PPP)".
[22] Request For Comment (RFC) 1618: "PPP over ISDN".
[23] CCITT Recommendation T.90 (1992): "Characteristics and protocols for
terminals for telematic services in ISDN".
[24] ISO 8208 (1990): "Information technology: Data communications; X.25 Packet
Layer Protocol for Data Terminal Equipment".
[25] ITU-T Recommendation X.213 (1992): "Information technology - Network
service definition for Open Systems".
[26] ITU-T Recommendation X.400: "Reference model open System interconnection
for CCITT applications".
[27] ITU-T Recommendation X.200: "Message handling system and service
overview".
[28] ETS 300 097 (1992): "Integrated Services Digital Network (ISDN), Connected
Line Identification Presentation (COLP) supplementary service; Digital
Subscriber Signalling System No. one (DSS1) protocol part 1; Protocol
implementation description".
Page 11
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
3 Definitions and abbreviations
3.1 Definitions
For the purposes of this ETS, the following definitions and those given in ETS 300 838 [14] apply:
Invalidate SIM File This is a procedure to change the availability of a SIM file. With the invalidate
function, the corresponding file will no longer be available. See GSM 11.11 [13].
Rehabilitate SIM File This function will make a SIM file available for an application. See
GSM 11.11 [13].
RP cause This is an error cause used in the GSM Short Messages Service at the SMR
(Short Message Relay) layer. All causes are listed in GSM 04.11 [16].
3.2 Abbreviations
For the purpose of this ETS, the following abbreviations apply:
API Application Programming Interface
ASN1 Abstract Syntax Notation Number 1. This notation is used in different
GSM services.
CAPI COMMON-ISDN-API
CBS Cell Broadcast Service. It is a specific GSM service used to broadcast
messages to all subscribers. See GSM 03.41 [6].
DCS Data Coding Scheme. It defines an alphabet and/or a class and/or a language
for a message. It is used for the SMS and the CBS. See GSM 03.38 [4].
DTMF Dual Tone Multi Frequency.
GSM-API GSM Application Programming Interface.
HPCI Harmonized Programmable Communication Interface
MI Message Identifier. Each page of a CBS message is identified by a MI.
PIN Code Personal Identification Number. See GSM 11.11 [13].
PLMN Public Land Mobile Network.
PPP Point to Point Protocol.
RLP Radio Link Protocol.
SC Service Centre. It is the network element which handle the SMS messages.
SeeGSM 03.40 [5].
SIM Subscriber Identity Module. See GSM 11.11 [13] for a full description of the SIM
files.
SMS Short Message Service. It is a specific GSM service used to send point to point
short messages. See GSM 03.40 [5] for a complete description.
SMS Command It is a TPDU initiated from a mobile station which invoke an operation in the
service centre. See GSM 03.40 [5].
SS Supplementary Services. All GSM supplementary services are defined in
GSM 02.04 [2].
TPDU Transfer Protocol Data Unit. It is used in the Short Messages Service. See
GSM 03.40 [5].
4 Profile A compatible part of GSM-API
(replaces subclause 5.7 of ETS 300 838 [14]).
For further study.
Page 12
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
5 Profile B compatible part of GSM-API
(replaces subclause 6.8 of ETS 300 838 [14].)
5.1 Overview
This part of GSM-API defines the parameter description which replaces subclause 6.8 of
ETS 300 838 [14] (i.e. Parameter description of Profile B). This replacement is necessary to run existing
COMMON-ISDN-API applications on a GSM network.
5.2 Parameter description
This subclause describes the parameters used in ETS 300 838 [14] profile B messages. Each parameter
is listed with its type, possible values and reference to the messages in which the parameter appears.
Some parameter values are defined according to ETS 300 102-1 [15], Q.931 [16] or GSM 04.08 [7] and
04.11 [8]. In that case there is no private Profile B coding for these parameters. These parameters are
coded as Profile B structures starting with a length octet and the remainder of the parameter being coded
as defined in ETS 300 102-1 [15] / Q.931 [16] or GSM specifications from octet three onwards.
References to the contents of a structure in this clause always use index 0 to identify the first octet of
information, i.e. the octet following the length octet.
Parameters may not be omitted, instead an empty structure shall be used. An empty structure shall be
coded as a single octet containing a value of 0.
Reserved structures shall be coded as empty structures. Reserved parameter values shall not be used by
GSM-API applications. In case of COMMON-ISDN-API applications using these reserved structures
respective parameter values the behaviour of GSM-API is described below.
Default values as described in the following subclause shall be implemented in Profile B. They need not
be valid for external ISDN equipment; in that case the external equipment defines the default values for its
usage.
Parameters may again contain parameters which are referred to as "sub parameters".
The GSM specific extensions of some of the ETS 300 838 [14] profile B parameters are mentioned in this
subclause even if they are related to the GSM specific part in clause 7.
These values shall be used by either the application and the GSM-API if and only if the application has
asked for GSM support as described in the clause 7.3 of this ETS.

Page 13
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
5.2.1 Additional Info
Additional Info (struct)
The purpose of the parameter additional info is to exchange signalling protocol specific information of the
network. Depending on the signalling protocol only relevant elements of this structure shall be used (e.g.
the B channel information has to be ignored in the message DISCONNECT_REQ).
The parameter has the following structure:
struct B channel information;
struct reserved, shall be ignored;
struct User user data (coded according to ETS 300 102-1 [15] / Q.931 [16]);
struct reserved, shall be ignored.
This information element appears in:
ALERT_REQ
CONNECT_REQ
CONNECT_IND
CONNECT_RESP
DISCONNECT_REQ
INFO_REQ
5.2.2 B Channel Information
B Channel Information (struct)
The purpose of the sub parameter B channel information is to choose between B channel data exchange,
D channel data exchange or pure user-user data exchange. If this struct is empty the default value is
assumed.
This sub parameter is coded as a structure, to give an easy way of extending its contents in future
changes. At the moment, it is coded as a structure of two bytes length and has one element:
word Channel:
0 use B channel (default value);
1 reserved, shall be rejected;
2 reserved, shall be rejected.
This sub parameter appears in parameter:
Additional information.
Page 14
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
5.2.3 B Protocol
B Protocol (struct)
The purpose of the parameter B protocol is to select and configure the B channel protocols. There is a
protocol identifier and configuration information for each layer. If this struct is empty the default value is
assumed.
The parameter has the following structure:
word B1 protocol : Physical layer and framing;
word B2 protocol : Data link layer;
word B3 protocol : Network layer;
struct reserved, shall be ignored;
struct B2 configuration : Data link layer parameter;
struct B3 configuration : Network layer parameter;
This information element appears in:
CONNECT_REQ
CONNECT_RESP
SELECT_B_PROTOCOL_REQ
5.2.4 B1 Protocol
B1 Protocol (word)
The purpose of the sub parameter B1 protocol is to specify the physical layer and framing used for this
connection. In GSM-API following transfer modes shall be supported by the mobile station:
The following values are defined:
0 UDI mode with ISO3309 HDLC framing. This is the default B1 protocol;
1 analogue mode;
2 UDI mode without any additional framing;
3 reserved, shall be rejected;
4 fax G3 mode;
5 UDI mode with ISO3309 HDLC framing (for compatibility to existing
applications);
6 analogue mode (for compatibility to existing applications).
protocol 0 and 5 shall establish an UDI connection where layer two frames additionally are encapsulated
by an HDLC framing structure with byte stuffing according to ISO 3309.

Page 15
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
This sub parameter appears in parameter:
B protocol
5.2.5 B2 Protocol
B2 Protocol (word)
The purpose of the sub parameter B2 protocol is to specify the data link layer used for this connection.
The following values are defined:
0 ISO 7776 [17] (X.75 SLP) This is the default B2 protocol;
1 Transparent;
2 SDLC [18];
3 LAPD according Q.921 [19] for D channel X.25;
4 T.30 [20] for fax group 3;
5 Point to Point Protocol (PPP [21] [22]);
6 Transparent (ignoring framing errors of B1 protocol).
This sub parameter appears in parameter:
B protocol
5.2.6 B3 Protocol
B3 Protocol (word)
The purpose of the sub parameter B3 protocol is to specify the network layer used for this connection.
The following values are defined:
0 Transparent. This is the default B3 protocol;
1 T.90NL with compatibility to T.70NL according to T.90 Appendix II [23];
2 ISO 8208 [24] (X.25 DTE-DTE);
3 X.25 DCE;
4 T.30 [20] for fax group 3.
This sub parameter appears in parameter:
B protocol
Page 16
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
5.2.7 B1 Configuration
B1 Configuration (struct)
reserved, shall be ignored
This sub parameter appears in parameter:
B protocol
5.2.8 B2 Configuration
B2 Configuration (struct)
The purpose of the sub parameter B2 configuration is to offer additional configuration information for B2
protocol. It is only used for B2 protocols 0, 2 and 3. The parameter has the following structure:
byte Address A This parameter has different meaning and default values de-
pending on the selected B2 protocol:
### B2 protocol 0: link Address A, default is 0x03
### B2 protocol 2: link Address, default is 0xC1
### B2 protocol 3: bit 0: ´0´ - automatic TEI assignment proce-
dure shall be used. ´1´ - the TEI value shall be used as fixed
TEI. In this case Bit 7 - Bit 1: TEI value
byte Address B This parameter has different meaning and default values de-
pending on the selected B2 protocol:
### B2 protocol 0: link Address B, default is 0x01
### B2 protocol 2: not applicable
### B2 protocol 3: not applicable
byte Modulo Mode Mode of operation:
### 8 - normal operation (Default)
### 128 - extended operation
byte Window Size Window size, default is 7.
struct XID This parameter has different meaning and default values de-
pending on the selected B2 protocol:
### B2 protocol 0: not applicable
### B2 protocol 2: this is the content of the XID response
which is sent when a XID command is received.
### B2 protocol 3: not applicable
This sub parameter appears in parameter:
B protocol
5.2.9 B3 Configuration
B3 Configuration (struct)
The purpose of the sub parameter B3 configuration is to offer additional configuration information for B3
protocol. Different structures of this parameter are defined, depending on the B3 protocol:
For B3 protocols 0 (transparent) this parameter does not apply (coded as an empty structure).
For B3 protocols 1, 2 and 3 (T.90NL, ISO8208, X.25 DCE) the following structure is defined:

Page 17
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
word LIC Lowest incoming channel, default is 0
word HIC Highest incoming channel, default is 0
word LTC Lowest two-way channel, default is 1
word HTC Highest two-way channel, default is 1
word LOC Lowest outgoing channel, default is 0
word HOC Highest outgoing channel, default is 0
word Modulo Mode Mode of operation:
### 8 - normal operation (default)
### 128 - extended operation
word Window Size Used to configure non-standard defaults for the transmit and
receive window size, default is 2
For B3 protocol 4 (Fax G3) the following structure is used:
word resolution 0: standard
1: high
word format 0: SFF (Default, description in annex B)
1: Plain FAX Format (modified Huffman coding)
2: PCX
3: DCX
4: TIFF
5: ASCII
6: Extended ANSI
7: Binary-File transfer
struct station id ID of the calling station. Coded in ASCII
struct head line Headline sent on each fax page. Coded in ASCII
This sub parameter appears in parameter:
B protocol
5.2.10 BC
BC (struct)
reserved, shall be ignored
This information element appears in:
CONNECT_IND
CONNECT_REQ
5.2.11 Called Party Number
Called Party Number (struct)
The purpose of the parameter called party number information element is to identify the called party of a
call. The information element is coded according to ETS 300 102-1 [15] / Q.931 [16].
Byte 0 Type of number and numbering plan identification (byte 3 of the called
party number information element, see ETS 300 102 [15]).
At the calling side the value supplied by the application shall be
transmitted over the network, 0x80 is the suggested default value.
At the called side the value received from the network shall be passed
to the application.
Bytes 1.n Number digits of the called party number information element.
This information element appears in:

Page 18
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
CONNECT_IND
CONNECT_REQ
5.2.12 Called Party Subaddress
Called Party Subaddress (struct)
The purpose of the parameter called party subaddress is to identify the subaddress of the called party of a
call. The information element is coded according to ETS 300 102-1 [15] / Q.931 [16].
Byte 0 Type of subaddress
At the calling side the value supplied by application shall be
transmitted over the network, 0x80 is the suggested default value
(NSAP according X.213 [25]). In this case, the first subaddress
information octet should have the value 0x50.
At the called side, the value received from the network shall be passed
to the application.
Bytes 1.n Contents of the called party subaddress information element.
This information element appears in:
CONNECT_REQ
CONNECT_IND
5.2.13 Calling Party Number
Calling Party Number (struct)
reserved, shall be ignored.
This information element appears in:
CONNECT_REQ
CONNECT_IND
LISTEN_REQ
5.2.14 Calling Party Subaddress
Calling Party Subaddress (struct)
The purpose of the parameter calling party subaddress information element is to identify a subaddress
associated with the origin of a call. The information element is coded according to ETS 300 102-1 [15] /
Q.931 [16].
Byte 0 Type of subaddress
At the calling side the value supplied by application shall be
transmitted over the network, 0x80 is the suggested default value
(NSAP according X.213 [25]). In this case, the first subaddress
information octet should have the value 0x50.
At the called side, the value received from the network shall be passed
to the application.
Bytes 1.n Contents of the calling party subaddress information element.
This information element appears in:
CONNECT_IND
Page 19
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
CONNECT_REQ
LISTEN_REQ
5.2.15 CIP Value
CIP Value (word)
The purpose of parameter CIP Value is to identify a complete profile of compatibility information (Bearer
Capability, Low Layer Compatibility and High Layer Compatibility). With this parameter standard
applications are not required to do complex coding and decoding of the above mentioned information
elements.
Some of the CIP values only define a Bearer Capability (CIP 1 to 9) and some values define a
combination of Bearer Capability and High Layer Compatibility (CIP 16 to 34). A Low Layer Compatibility
information element is not defined with the CIP. The Low Layer Compatibility information element may be
provided by the application if necessary. The following CIP values are defined:

Page 20
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
CIP value Service Relation to call
0 no predefined profile
Speech voice call
2 unrestricted digital UDI call using RLP(see note)
information
3 restricted digital in- UDI call using RLP(see note)
formation
4 3,1 kHz audio voice call
5 7 kHz audio reserved, shall be rejected
video reserved, shall be rejected
7 packet mode reserved, shall be rejected
56 kBit/s rate UDI call using RLP(see note)
adaptation
9 unrestricted digital reserved, shall be rejected
information with
tones/announceme
nts
reserved
10.15
16 Telephony Bearer Capability according to CIP 1.
High Layer Compatibility:
coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification: Telephony
Coding of HLC:
<0x7D, 0x02, 0x91, 0x81>
Facsimile Group fax G3 call
2/3
18 Facsimile Group 4 Bearer Capability according to CIP 2.
Class 1 High Layer Compatibility:
coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification: Facsimile
Group 4 Class 1
Coding of HLC:
<0x7D, 0x02, 0x91, 0xA1>
Teletex service Bearer Capability according to CIP 2.
basic and mixed
mode and High Layer Compatibility:
facsimile service coding standard: CCITT
Group 4 Classes II interpretation: First characteristics identification is
and III to be used
Presentation: High layer protocol profile
High layer characteristics identification. Teletex
service and facsimile service Group 4
Coding of HLC:
<0x7D, 0x02, 0x91, 0xA4>
(continued)
Page 21
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
(continued)
CIP value Service Relation to call
20 Teletex service Bearer Capability according to CIP 2.
basic and High Layer Compatibility:
processable mode coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification. Teletex
service basic and processable mode
Coding of HLC:
<0x7D, 0x02, 0x91, 0xA8>
21 Teletex service Bearer Capability according to CIP 2.
basic mode High Layer Compatibility:
coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification. Teletex
service basic mode
Coding of HLC:
<0x7D, 0x02, 0x91, 0xB1>
International inter Bearer Capability according to CIP 2.
working for High Layer Compatibility:
Videotex coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification.
International inter working for Videotex
Coding of HLC:
<0x7D, 0x02, 0x91, 0xB2>
Telex Bearer Capability according to CIP 2.
High Layer Compatibility:
coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification: Telex
Coding of HLC:
<0x7D, 0x02, 0x91, 0xB5>
24 Message Handling Bearer Capability according to CIP 2.
Systems accordingHigh Layer Compatibility:
to X.400 [26] coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification: Message
Handling Systems according X.400
Coding of HLC:
<0x7D, 0x02, 0x91, 0xB8>
(continued)
Page 22
ETS 300 917 (GSM 07.08 version 5.2.1): May 1998
(concluded)
CIP value Service Relation to call
25 OSI application Bearer Capability according to CIP 2.
according to High Layer Compatibility:
X.200 [27] coding standard: CCITT
interpretation: First characteristics identification is
to be used
Presentation: High layer protocol profile
High layer characteristics identification: OSI
application according X.200
Coding of HLC:
<0x7D, 0x02, 0x91, 0xC1>
26 7 kHz Telephony reserved, shall be rejected
Video Telephony, reserved, shall be rejected
first connection
28 Video Telephony, reserved, shall be rejected
second connection
Modem modem call 8 data bits, no parity, 1 stop bit. Used
only, if GSM services are requested.
33 Modem modem call 7 data bits, even parity, 1 stop bit.
Used only, if GSM services are requested.
In Call modificationuse of In Call modification (TS.61 only). Used only,
TS.61 if GSM services are requested.
NOTE: RLP can be disabled by manufacturer specific mechanism. User rate and other subscription
dependent parameter are manufacturer dependent and not part of GSM-API. They should be
configurable by manufacturer specific mechanism.
This information element appears in:
CONNECT_REQ
CONNECT_IND
5.2.16 CIP mask
CIP mask (dword)
The purpose of the parameter CIP mask is to select basic classes of incoming calls. The bit position within
this mask identifies the related CIP value. When an incoming call is received, Profile B tries to match this
incoming call to the d
...