<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with SAPE SAP Editor -->
<SAP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="sap.xsd">
    <DocInfoSection>
        <DocName DocType="SAP">tom</DocName>
        <DocNum Number="119" Project="6368"/>
        <Description>
            <Section>The Protocol Stacks are used to define the functionality of the GSM protocols for interfaces. The GSM specifications are normative when used to describe the functionality of interfaces, but the stacks and the subdivision of protocol layers does not imply or restrict any implementation.</Section>
            <Section>The protocol stack for GPRS consists of several entities. Each entity has one ore more service access points, over which the entity provides a service for the upper entity.</Section>
            <Section>Figure 1-1: Architecture of the GSM/GPRS protocol stack</Section>
            <Section>The information units passed via the SAPs are called primitives and consists of an operation code and several parameters. See the Users Guide for details.</Section>
            <Section>The entities of the GPRS protocol stack are:</Section>
            <Section>1.1 GRR (RLC/MAC) - Radio Link Control/Medium Access Control</Section>
            <Section>This layer contains two functions: The Radio Link Control function provides a radio-solution-dependent reliable link. The Medium Access Control function controls the access signalling (request and grant) procedures for the radio channel, and the mapping of LLC frames onto the GSM physical channel.</Section>
            <Section>1.2 LLC - Logical Link Control</Section>
            <Section>The LLC entity provides multiple highly reliable logical links for asynchronous data transfer between the MS and the network. It supports variable-length information frames, acknowledged and unacknowledged data transfer, flow and sequence control, error detection and recovery, notification of unrecoverable errors, user identity confidentiality, and ciphering of user and signaling data.</Section>
            <Section>1.3 GMM - GPRS Mobility Management</Section>
            <Section>The GMM entity provides procedures for the mobility of the MS, such as informing the network of its present location, and user identity confidentiality. It manages the GMM context (attach, detach, routing area updating), supports security functions such as authentication of user and MS, controls ciphering of data, and initiates the response to paging messages.</Section>
            <Section>1.4 SM - Session Management</Section>
            <Section>The main function of the session management (SM) is to support PDP context handling of the user terminal. Session Management activates, modifies and deletes the contexts for packet data protocols (PDP). Session Management services are provided at the SMREG-SAP and the SNSM-SAP for anonymous and non-anonymous access. The non-anonymous and anonymous access procedures for PDP context activation and PDP context deactivation are available at the SMREG-SAP. In addition there exists a PDP context modification for non-anonymous PDP contexts.</Section>
            <Section>1.5 SNDCP - Subnetwork Dependant Convergence Protocol</Section>
            <Section>SNDCP carries out all functions related to transfer of Network layer Protocol Data Units (N-PDUs) over GPRS in a transparent way. SNDCP helps to improve channel efficiency by means of compression techniques. The set of protocol entities above SNDCP consists of commonly used network protocols. They all use the same SNDCP entity, which then performs multiplexing of data coming from different sources to be sent using the service provided by the LLC layer.</Section>
            <Section>1.6 GACI - GPRS Application Control Interface</Section>
            <Section>The GACI is the GPRS extension of the ACI. It is specified in GSM 07.07 and 07.60. It is responsible for processing of the GPRS related AT Commands to setup, activate and deactivate the PDP context parameter. It also provides functionality for the interworking between GMM/SM/SNDCP and a packet oriented protocol like PPP.</Section>
            <Section>1.7 USART - Universal Synchronous Asynchronous Receiver Transmitter Driver</Section>
            <Section>The USART is a hardware component that facilitates a connection between the mobile station and terminal equipment (e.g. a PC). This interface uses some of the circuits described in V.24.</Section>
            <Section>The data exchange provided by this unit is serial and asynchronous (synchronous communication is not in the scope of this document). A driver that uses interrupts to manage a circular buffer for the sending and receiving direction is necessary in order to use this component in the GPRS. The driver has to be able to perform flow control.</Section>
            <Section>1.8 TOM - Tunnelling of Messages</Section>
            <Section>The TOM entity is present if and only if HS136 is supported (the feature flag FF_HS136 is enabled).</Section>
            <Section>The main function of TOM is to tunnel non-GSM signalling messages between the MS and the SGSN. The only non-GSM signalling which is currently supported by TOM is for the EGPRS-136 system (according to TIA/EIA-136-376). Data transfer in both uplink and downlink direction is possible. Two different priorities (high, low) of signalling data transfer are supported. TOM uses the unacknowledged mode of LLC and the acknowledged mode of GRR (RLC/MAC).</Section>
        </Description>
        <DocHistory>
            <DocVersion Number="001" Year="00"/>
            <Date Day="27" Month="7" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Initial version</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="002" Year="00"/>
            <Date Day="28" Month="7" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Removed requirement to have space for the LLC FCS in the SDU as lower layer data passing (CCI interworking) is changed.</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="003" Year="00"/>
            <Date Day="2" Month="8" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Removed requirement to have space for the LLC header as the SDU will be copied by to the primitive of LL.</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="004" Year="00"/>
            <Date Day="15" Month="8" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Substituted figure 1-1 with picture showing TOM and PPC (SAP). Update with &quot;AKT&quot; macro now running in the English version as well; changed to Condat AG</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="005" Year="00"/>
            <Date Day="28" Month="8" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Changed to Condat AG</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="006" Year="00"/>
            <Date Day="9" Month="10" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>New figure 1-1 showing also CCI SAP</Comment>
        </DocHistory>
        <DocHistory>
            <DocVersion Number="007" Year="00"/>
            <Date Day="13" Month="10" Year="2000"/>
            <Author>SBK</Author>
            <DocStatus State="BEING_PROCESSED"/>
            <Comment>Update references; modified note in ch. 4.4</Comment>
        </DocHistory>
        <DocRef>
            <RefId>[1]</RefId>
            <RefTitle>GSM 05.02 version 8.0.0 Release 1999Digital cellular telecommunications system (Phase 2+);Multiplexing and multiple access on the radio path</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[2]</RefId>
            <RefTitle>GSM 04.60 version 6.3.0 Release 1997Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);Mobile Station (MS) - Base Station System (BSS) interface;Radio Link Control/ Medium Access Control (RLC/MAC) protocol</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[3]</RefId>
            <RefTitle>GSM 04.08 version 6.3.0 Release 1997Digital cellular telecommunications system (Phase 2+);Mobile radio interface layer 3 specification</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[4]</RefId>
            <RefTitle>GSM 03.64 version 6.1.0 Release 1997Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);Overall description of the GPRS radio interface; Stage 2</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[5]</RefId>
            <RefTitle>GSM 03.60 version 6.3.1 Release 1997Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);Service description; Stage 2</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[6]</RefId>
            <RefTitle>GSM 04.07 version 6.3.0 Release 1997Digital cellular telecommunications system (Phase 2+);Mobile radio interface signalling layer 3; General aspects</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[7]</RefId>
            <RefTitle>GSM 04.64 version 6.3.0 Release 1997Digital cellular telecommunications system (Phase 2+);General Packet Radio Service (GPRS);Mobile Station - Serving GPRS Support Node (MS-SGSN)Logical Link Control (LLC) layer specification</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[8]</RefId>
            <RefTitle>GSM 05.08 version 6.4.0 Release 1997Digital cellular telecommunications system (Phase 2+);Radio subsystem link control</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[9]</RefId>
            <RefTitle>GSM 05.10 version 6.3.0 Release 1997Digital cellular telecommunications system (Phase 2+);Radio subsystem synchronization</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[10]</RefId>
            <RefTitle>GSM 03.20 TS 100 929: July 1998 (GSM 03.20 version 6.0.1)Security related network functions, ETSI</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[11]</RefId>
            <RefTitle>Draft GSM 03.22: August 1998 (GSM 03.22 version 6.1.0)Functions related to Mobile Station (MS) in idle mode and group receive mode, ETSI</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[12]</RefId>
            <RefTitle>GSM 04.65 V6.3.0: Subnetwork Dependant Convergence Protocol ETSI, March 1999</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[13]</RefId>
            <RefTitle>ITU-T V42bis ITU-T, Recommendation V.42 bis 1990</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[14]</RefId>
            <RefTitle>GSM 09.60 GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[15]</RefId>
            <RefTitle>RFC 1661 IETF STD 51 July 1994The Point-to-Point Protocol (PPP)</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[16]</RefId>
            <RefTitle>RFC 1662 IETF STD 51 July 1994PPP in HDLC-like Framing</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[17]</RefId>
            <RefTitle>RFC 1570 January 1994PPP LCP Extensions</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[18]</RefId>
            <RefTitle>RFC 1989 August 1996PPP Link Quality Monitoring</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[19]</RefId>
            <RefTitle>RFC 1332 May 1992The PPP Internet Protocol Control Protocol (IPCP)</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[20]</RefId>
            <RefTitle>RFC 1877 December 1995PPP IPCP Extensions for Name Server Addresses</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[21]</RefId>
            <RefTitle>RFC 2153 May 1997PPP Vendor Extensions</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[22]</RefId>
            <RefTitle>RFC 1334 October 1992PPP Authentication Protocols (for Password Authentication Protocol only)</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[23]</RefId>
            <RefTitle>RFC 1994 August 1996PPP Challenge Handshake Authentication Protocol (CHAP)</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[24]</RefId>
            <RefTitle>TIA/EIA-136-370Packet-Data Services - Enhanced General Packet Radio for TIA/EIA-136 (EGPRS-136) - Overview, Telecommunications Industry Association</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[25]</RefId>
            <RefTitle>TIA/EIA-136-376Packet-Data Services - EGPRS-136 Mobility Management, Telecommunications Industry Association</RefTitle>
        </DocRef>
        <DocRef>
            <RefId>[26]</RefId>
            <RefTitle>TIA/EIA-136-972Packet-Data Services - Stage 2 Description, Telecommunications Industry Association</RefTitle>
        </DocRef>
    </DocInfoSection>
    <ConstantsSection>
        <Description>
            <Section>This section contains all constants that are defined for the TOM SAP</Section>
        </Description>
        <Constant>
            <Alias>TOM_SDU_OFFSET_BITS</Alias>
            <Value ValueType="DEC">4</Value>
            <Comment>offset used for the SDU containing the TOM Protocol Envelope; these bits are used by the TOM Protocol Discriminator (4 bits); to avoid copying of data, these bits at the start of the TOM Protocol Envelope are part of the SDU but need to be skipped when upper layers write / read the contents of the SDU</Comment>
        </Constant>
        <History>
            <Date Day="27" Month="7" Year="2000"/>
            <Author>SBK</Author>
            <Comment>Initial</Comment>
        </History>
        <History>
            <Date Day="28" Month="7" Year="2000"/>
            <Author>SBK</Author>
            <Comment>Removed constant for tail bits</Comment>
        </History>
        <History>
            <Date Day="2" Month="8" Year="2000"/>
            <Author>SBK</Author>
            <Comment>Changed constant for header bits to 4, i.e. to only include the TOM offset and not the octets required for the LLC header as the SDU will be copied to the LL primitive</Comment>
        </History>
    </ConstantsSection>
    <PrimitivesSection PrimIDType="BIT16" SAPid="57">
        <Description>
            <Section>This section contains all primitives that are defined for the TOM SAP</Section>
        </Description>
        <Primitive>
            <Description>
                <Section>This primitive is used to request the transmission of a TOM SDU, i.e. data corresponding to higher layer (e.g. 136MM) PDU(s), to the peer entity at the network side. The data will be transmitted using the unacknowledged, but protected mode of LLC and the acknowledged mode of RLC.</Section>
                <Section>Note: For the higher layer being 136MM, this primitive realises the primitive RPDCH_REQ of TIA/EIA-136-376.</Section>
                <Section>The parameter service access point identifier specifies which higher layer requests the service of TOM.</Section>
                <Section>The parameter tunnel priority indicates with which priority TOM should send the requested data.</Section>
                <Section>The parameter cipher mode indicates if the resulting TOM PDU is ciphered before the transmission or not.</Section>
                <Section>Parameter service data unit will contain the TOM Protocol Discriminator field, followed by the Remaining Length of TOM Protocol Header field, followed by the optional Remaining Octets of TOM Protocol Header field, and finally followed by the Message Capsule field. It is the responsibility of the TOM service user to put the encoded fields</Section>
                <Section>1) Remaining Length of TOM Protocol Header</Section>
                <Section>2) optionally Remaining Octets of TOM Protocol Header and</Section>
                <Section>3) Message Capsule</Section>
                <Section>at the correct place into the service data unit parameter. Therefore, the offset TOM_SDU_OFFSET_BITS specified in chapter 2 has to be applied. Format and coding of the above mentioned three fields has to follow GSM 04.64 and the appropriate TOM service user specifications.</Section>
            </Description>
            <PrimDef>
                <Name>TOM_DATA_REQ</Name>
                <PrimID Direction="UPLINK" Number="0"/>
                <PrimUsage>
                    <Sender>higher</Sender>
                    <Receiver>layer</Receiver>
                </PrimUsage>
            </PrimDef>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>sapi</Name>
                </ItemLink>
                <Comment>service access point identifier</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>tunnel_prio</Name>
                </ItemLink>
                <Comment>tunnel priority</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>cipher</Name>
                </ItemLink>
                <Comment>cipher mode</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>sdu</Name>
                </ItemLink>
                <Comment>service data unit</Comment>
            </PrimItem>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
            <History>
                <Date Day="28" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Removed requirement for space for tail bits for lower layers (LLC)</Comment>
            </History>
            <History>
                <Date Day="2" Month="8" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Changed constant for header bits to 4, i.e. to only include the TOM offset and not the octets required for the LLC header as the SDU will be copied to the LL primitive</Comment>
            </History>
        </Primitive>
        <Primitive>
            <Description>
                <Section>This primitive is used to indicate the reception of a TOM SDU, i.e. data belonging to higher layer (e.g. 136MM) PDU(s) from the peer TOM entity at the network side. The data was received in the unacknowledged, but protected mode of LLC and the acknowledged mode of RLC.</Section>
                <Section>Note: For the higher layer being 136MM, this primitive realises the primitive FPDCH_IND of TIA/EIA-136-376.</Section>
                <Section>The parameter service access point identifier specifies for which higher layer the data is. Here, this parameter needs not to be checked by the higher layer and recommended to be ignored.</Section>
                <Section>The parameter tunnel priority indicates the priority which was used for the transmission at the TOM level.</Section>
                <Section>The parameter cipher mode indicates if the received TOM PDU was ciphered or not.</Section>
                <Section>Parameter service data unit contains the Remaining Length of TOM Protocol Header field, followed by the optional Remaining Octets of TOM Protocol Header field, followed by the Message Capsule. It is the responsibility of the TOM service user to decode and perform any necessary validity check on the fields</Section>
                <Section>1) optional Remaining Octets of TOM Protocol Header and</Section>
                <Section>2) Message Capsule</Section>
                <Section>.</Section>
            </Description>
            <PrimDef>
                <Name>TOM_DATA_IND</Name>
                <PrimID Direction="DOWNLINK" Number="0"/>
                <PrimUsage>
                    <Sender>TOM</Sender>
                    <Receiver>higher</Receiver>
                </PrimUsage>
            </PrimDef>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>sapi</Name>
                </ItemLink>
                <Comment>service access point identifier</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>tunnel_prio</Name>
                </ItemLink>
                <Comment>tunnel priority</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>cipher</Name>
                </ItemLink>
                <Comment>cipher mode</Comment>
            </PrimItem>
            <PrimItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>sdu</Name>
                </ItemLink>
                <Comment>service data unit</Comment>
            </PrimItem>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </Primitive>
    </PrimitivesSection>
    <PrimStructElementsSection>
        <Description>
            <Section>Parameters shall be part of the primitives described above and if applied the parameters shall contain the values specified here (except those marked as reserved or invalid - these shall never be used with the current version of this SAP).</Section>
        </Description>
        <PrimStructElem>
            <Description>
                <Section>This parameter contains a TOM SDU. For details please refer to the descriptions of the primitives using this parameter (see chapter 3.1, 3.2).</Section>
                <Section>Note: TOM service users need to ensure that the appropriate standard header file (&quot;header.h&quot;) defining sdu is included. This is because sdu is excluded from automatic generation from this document.</Section>
            </Description>
            <PrimStructElemDef Type="STRUCT">
                <Name>sdu</Name>
                <Comment>service data unit</Comment>
            </PrimStructElemDef>
            <PrimStructElemItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>l_buf</Name>
                </ItemLink>
                <Comment>length of content in bit</Comment>
            </PrimStructElemItem>
            <PrimStructElemItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>o_buf</Name>
                </ItemLink>
                <Comment>offset of content in bit</Comment>
            </PrimStructElemItem>
            <PrimStructElemItem Presentation="MANDATORY">
                <ItemLink>
                    <DocName DocType="SAP">tom</DocName>
                    <Name>buf</Name>
                </ItemLink>
                <Control>[1]</Control>
                <Comment>buffer content</Comment>
            </PrimStructElemItem>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimStructElem>
    </PrimStructElementsSection>
    <PrimBasicElementsSection>
        <Description>
            <Section>Parameters shall be part of the primitives described above and if applied the parameters shall contain the values specified here (except those marked as reserved or invalid - these shall never be used with the current version of this SAP).</Section>
        </Description>
        <PrimBasicElem>
            <Description>
                <Section>Service access point identifier specifies which higher layer requests the services of TOM or perceives the services of TOM.</Section>
                <Section>Note: This parameter is already present to allow future extensibility in the sense that more than one entity / technology could use the services of TOM. It is also the basis for selection of the TOM Protocol Discriminator in the uplink direction.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>sapi</Name>
                <Type>U8</Type>
                <Comment>service access point identifier</Comment>
            </PrimBasicElemDef>
            <ValuesLink>
                <DocName DocType="SAP">tom</DocName>
                <Name>VAL_sapi</Name>
            </ValuesLink>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
        <PrimBasicElem>
            <Description>
                <Section>The parameter tunnel priority indicates with which priority is used in transmission of TOM data.</Section>
                <Section>Note: This parameter is already present to allow future extensibility in the sense that more than one entity could use the services of TOM.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>tunnel_prio</Name>
                <Type>U8</Type>
                <Comment>tunnel priority</Comment>
            </PrimBasicElemDef>
            <ValuesLink>
                <DocName DocType="SAP">tom</DocName>
                <Name>VAL_tunnel_prio</Name>
            </ValuesLink>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
        <PrimBasicElem>
            <Description>
                <Section>When used in the uplink direction, this parameter defines if the corresponding TOM PDU is to be ciphered or not before transmission over the air interface. When used in the downlink direction, this parameter  indicates if the corresponding received TOM PDU was ciphered or not. The coding follows TIA/EIA-136-376.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>cipher</Name>
                <Type>U8</Type>
                <Comment>cipher mode</Comment>
            </PrimBasicElemDef>
            <ValuesLink>
                <DocName DocType="SAP">tom</DocName>
                <Name>VAL_cipher</Name>
            </ValuesLink>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
        <PrimBasicElem>
            <Description>
                <Section>This parameter contains a TOM SDU. For details please refer to the descriptions of the primitives using this parameter (see chapter 3.1, 3.2).</Section>
                <Section>Note: TOM service users need to ensure that the appropriate standard header file (&quot;header.h&quot;) defining sdu is included. This is because sdu is excluded from automatic generation from this document.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>l_buf</Name>
                <Type>U16</Type>
                <Comment>length of content in bit</Comment>
            </PrimBasicElemDef>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
        <PrimBasicElem>
            <Description>
                <Section>This parameter contains a TOM SDU. For details please refer to the descriptions of the primitives using this parameter (see chapter 3.1, 3.2).</Section>
                <Section>Note: TOM service users need to ensure that the appropriate standard header file (&quot;header.h&quot;) defining sdu is included. This is because sdu is excluded from automatic generation from this document.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>o_buf</Name>
                <Type>U16</Type>
                <Comment>offset of content in bit</Comment>
            </PrimBasicElemDef>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
        <PrimBasicElem>
            <Description>
                <Section>This parameter contains a TOM SDU. For details please refer to the descriptions of the primitives using this parameter (see chapter 3.1, 3.2).</Section>
                <Section>Note: TOM service users need to ensure that the appropriate standard header file (&quot;header.h&quot;) defining sdu is included. This is because sdu is excluded from automatic generation from this document.</Section>
            </Description>
            <PrimBasicElemDef>
                <Name>buf</Name>
                <Type>U8</Type>
                <Comment>buffer content</Comment>
            </PrimBasicElemDef>
            <History>
                <Date Day="27" Month="7" Year="2000"/>
                <Author>SBK</Author>
                <Comment>Initial</Comment>
            </History>
        </PrimBasicElem>
    </PrimBasicElementsSection>
    <ValuesSection>
        <Description>
            <Section>This section contains all sets of values that are defined for the TOM SAP</Section>
        </Description>
        <Values>
            <Description>
                <Section>This former local values table was generated by the doc2XML converter tool. Please exchange this description by a more meaningful one !!!</Section>
            </Description>
            <ValuesDef>
                <Name>VAL_sapi</Name>
                <Comment>values for sapi</Comment>
            </ValuesDef>
            <ValuesItem>
                <Value ValueType="DEC">1</Value>
                <Alias>TOM_SAPI_136MM</Alias>
                <Comment>SAPI for (E)GPRS-136, 136MM</Comment>
            </ValuesItem>
            <ValuesDefault>
                <Comment>Invalid, reserved for future use</Comment>
            </ValuesDefault>
            <History>
                <Date Day="4" Month="11" Year="2003"/>
                <Author>doc2XML</Author>
                <Comment>Initial</Comment>
            </History>
        </Values>
        <Values>
            <Description>
                <Section>This former local values table was generated by the doc2XML converter tool. Please exchange this description by a more meaningful one !!!</Section>
            </Description>
            <ValuesDef>
                <Name>VAL_tunnel_prio</Name>
                <Comment>values for tunnel_prio</Comment>
            </ValuesDef>
            <ValuesItem>
                <Value ValueType="DEC">0</Value>
                <Alias>TOM_TUNNEL_PRIO_0</Alias>
                <Comment>High priority, 00, corresponds to TOM2</Comment>
            </ValuesItem>
            <ValuesItem>
                <Value ValueType="DEC">1</Value>
                <Alias/>
                <Comment>Invalid, reserved for future use</Comment>
            </ValuesItem>
            <ValuesItem>
                <Value ValueType="DEC">2</Value>
                <Alias>TOM_TUNNEL_PRIO_2</Alias>
                <Comment>Low priority, 10, corresponds to TOM8</Comment>
            </ValuesItem>
            <ValuesItem>
                <Value ValueType="DEC">3</Value>
                <Alias/>
                <Comment>Invalid, reserved for future use</Comment>
            </ValuesItem>
            <ValuesDefault>
                <Comment>Invalid, out of 2 bit range of TIA/EIA-136-376</Comment>
            </ValuesDefault>
            <History>
                <Date Day="4" Month="11" Year="2003"/>
                <Author>doc2XML</Author>
                <Comment>Initial</Comment>
            </History>
        </Values>
        <Values>
            <Description>
                <Section>This former local values table was generated by the doc2XML converter tool. Please exchange this description by a more meaningful one !!!</Section>
            </Description>
            <ValuesDef>
                <Name>VAL_cipher</Name>
                <Comment>values for cipher</Comment>
            </ValuesDef>
            <ValuesItem>
                <Value ValueType="DEC">0</Value>
                <Alias>TOM_CIPHER_OFF</Alias>
                <Comment>TOM PDU not ciphered</Comment>
            </ValuesItem>
            <ValuesItem>
                <Value ValueType="DEC">1</Value>
                <Alias>TOM_CIPHER_ON</Alias>
                <Comment>TOM PDU ciphered</Comment>
            </ValuesItem>
            <ValuesDefault>
                <Comment>Invalid</Comment>
            </ValuesDefault>
            <History>
                <Date Day="4" Month="11" Year="2003"/>
                <Author>doc2XML</Author>
                <Comment>Initial</Comment>
            </History>
        </Values>
    </ValuesSection>
</SAP>