Communication system and method

S P E C I F I C A T I O N

0002TITLE QF THE INVENTION Communication System And Method Related Application Data

0003This application is a continuation-in-part application of copending U.S. Application Serial No. 08/532,466 filed on September 22, 1995 and hereby incorporated by reference as if fully set forth herein, which is a continuation-in-part application of copending U.S. Application Serial No. 08/284,053 filed on August 1, 1994, which is a continuation-in-part of U.S. Application Serial No. 08/215,306 filed on March 21, 1994, now abandoned, which is a continuation-in-part of U.S. Application Serial No. 08/146,496 filed on November 1, 1993, now abandoned.

BACKGROUND OF THE INVENTION

00051) Field of the Invention

0006The field of this invention pertains to communications and, more particularly, to means for transferring information within a mobile communication system.

00072) Description of the Related Art

0008Digital communication systems have become increasingly popular for many applications. One advantage of a digital communication system is the flexibility to carry many different types of information over a single system. A single digital communication system may be used, for example, to transmit digitized sound, text, computer data, digital video, or other information existing in digital form.

0009To achieve flexibility, a communication system may be designed to transfer digital information from one end user to another in a transparent fashion. The communication system then operates as a transparent data pipeline for one or more other systems which are called application end users. Each application end user connected to the communication system generally has the responsibility for ensuring that the data ultimately delivered is in a form which is properly recognized by the user. To better achieve such flexibility, it has been suggested that a communication system be designed with a layered architecture . One example of a general layered architecture for digital communication systems is the International Organization for Standardization (ISO) Reference Model for Open Systems Interconnection ("OSI Reference Model") . The OSI Reference Model has been adopted as an international standard by the ISO and by the International Telephone and Telegraph Consultative Committee (CCITT) . Figure 4A is a diagram showing the OSI Reference Model

0010401. The OSI Reference Model 401 comprises a communication system having seven layers which form a communication path between a first end user 405 and a second end user 410. The seven layers may be divided into two sets--a set of upper layers 415 and a set of lower layers 420. The upper four layers 415 normally reside in the application end users desiring to communicate. A communication system may in some cases be defined by the lower three layers 420, individually known as the network layer 422, the data link layer 424 and the physical layer 426.

0011In the OSI Reference Model, each layer is responsible for specific, defined operations in the communication process between application end users 405, 410. In furtherance of these operations, each layer may communicate information with the layers above and below it through defined interfaces (although there is not always a definitive separation between layers) . Thus, for example, the transport layer may operate independently of the specific operational details of the network layer 422, the data link layer 424, and the physical layer 426 below it. The set of lower layers 420 thus operates as a transparent data pipeline to an application end user connected to the system at the transport layer interface.

0012Figure 4B illustrates a flow of data between layers such as may occur during communication between two application end users. As shown in Fig. 4B, information may be passed between like layers (e.g., the transport layer in the Fig. 4B example) of each end user through a path ultimately connected at the physical layer 426. The rules that govern how data is passed between like layers at each end user are collectively referred to as a "peer-to-peer protocol." A variety of different application end users operating with different peer- to-peer protocols may communicate over a communication system so long as each application end user presents the proper upper layer interface to the communication system. Conversely, an application end user may connect with any communication system having a compatible lower layer interface.

0013Additional details regarding the OSI Reference Model may be found in "Telecommunication Networks" by Mischa Schwartz (Addison-Wesley Publishing Co., 1987) .

0014One class of digital communication systems provides wireless data communication connections to stationary or mobile user stations (e.g., handsets) . Examples of such wireless mobile communication systems include public safety radio systems, cellular telephone systems, and personal communication systems (PCS) . A wireless communication system may include a number of base stations for completing communication paths with the user stations. The base stations may be connected to a network, either directly of via a switch. In many mobile communication systems it is desired that user stations have the ability to initiate and receive telephone calls. By connecting a communication system to a public switched telephone network (PSTN) , a user station may generally communicate with any telephone connected to the telephone network. Alternatively, a communication system may access the telephone system through an intermediate communication system such as the Global System for Mobile Communications (GSM) .

0015In operation, it is often necessary to pass signaling information among various components of a communication system. Signaling information may, for example, comprise control messages relating to the operation of the communication system. An example of signaling information is a message from a user station to a base station indicating a malfunction. One difficulty with the user of signaling information is that it must be distinguished within the system from data communication (i.e., information intended solely for the application end user) , and must be extracted by the system component needing the signaling information to perform its tasks. The transfer of necessary control and data information can be difficult within certain types of wireless systems. For example, in a time division multiple access (TDMA) system, wherein a base station communicates with a plurality of user stations (typically mobile) in a different time slots, the amount of information that can be transferred between the base station and the user station in a given time slot is necessarily limited. In contrast, a network to which a call is connected often transfers information in large data blocks (e.g., 64 kilobyte segments) . The base station should have the capability of supporting data transfers and control functions required by the network, while at the same time supporting the transfer of information and control messages to the user station over a TDMA channel . It would be advantageous to provide a mobile communication system with an improved method of communicating both user and signaling data among system components. It would be further advantageous to provide a mobile communication system having the characteristics of a layered architecture so as to provide a transparent data pipeline to application end users.

0016SUMMARY OF THE INVENTION The present invention comprises in one aspect a system and method of transferring information (including user data and signaling information) within a mobile communication system.

0017In one aspect of the invention, internal components of a mobile communication system communicate system signaling data across internal interfaces implemented according to a layered architecture. System interfaces effectively function as communication channels between the system components. The system components appear as application end users to the internal communication channels defined by the system interfaces . In another aspect of the invention, a mobile communication system transfers signaling data and end user data over a common set of interfaces, without using separate or dedicated internal communication channels for signaling data. In a preferred embodiment, the communication system includes a base station capable of communicating with a plurality of user stations. The base station is connected with a base station controller (which may also be connected to other base stations) . The base station controller may be connected to a network. In a preferred embodiment, the base station comprises two separate processors, an over-the-air (OTA) processor and a base station controller (BSC) interface processor (also called a line card processor) . The OTA processor controls a base station transceiver which carries out communication with user stations over communication links. In a preferred embodiment, the interface between the OTA processor and the line card processor comprises a dual-port RAM which is used as a shared resource across the interface. Prioritized queues may be used to facilitate response to relatively higher priority signaling and control messages .

0018In another aspect of the invention, an over-the-air interface provides for the transfer of signaling information or data information, or both. The over-the-air interface comprises a plurality of time division multiple access (TDMA) channels. An information packet sent over a TDMA channel includes a relatively long bearer field (B-field) and a relatively short byte-serial field (also called a D-field) . Low priority signaling messages may be segmented and transmitted over a plurality of time slots in the D-field. Higher priority signaling messages may be sent in the B-field, pre-empting normal bearer traffic. A field or flag in a header of an OTA information packet indicates to the receiving entity the usage of the B-field and the D-field for a given packet. In a particular embodiment of the invention where the interface between the base station and the user stations is a TDMA interface, signaling traffic between the base station and each of the user stations is conducted in either a fast control traffic mode or a slow control traffic mode. In the fast control traffic mode, signaling messages are exchanged between the base station and a user station in a plurality of time slots within a timespan of a single time frame; in the slow control traffic mode, signaling messages are exchanged between the base station and a user station in no more than a single time slot within a timespan of a single time frame.

0019The above aspects of the invention are described with respect to preferred sets of messages, wherein each set of messages is associated with a different interface between system components.

0020BRIEF DESCRIPTION OF THE DRAWINGS The various objects, features and advantages of the present invention may be better understood by examining the

0021Detailed Description of the Preferred Embodiments found below, together with the appended figures, wherein:

0022Fig. IA is a diagram of a pattern of cells in a wireless communication system. Fig. IB is a block diagram of a communication system.

0023Fig. IC is a diagram of an arrangement of cells in a wireless communication system showing an exemplary code and frequency reuse pattern.

0024Fig. 2 is a block diagram of a transmitter and a receiver in a spread spectrum communication system.

0025Fig. 3 is a diagram of a time frame divided into a plurality of time slots.

0026Fig. 4A is a diagram of a multi-layer communication system architecture according to the OSI Reference Model. Fig. 4B is a diagram illustrating peer-to-peer communication in the layered communication system architecture of Fig. 4A.

0027Fig. 5A is a diagram of a preferred slot structure, and Figs. 5B and 5C are diagrams of a base station traffic message structure and a user station traffic message structure, respectively.

0028Fig. 6 is an abstract diagram illustrating the transfer of information (including internal signaling messages) among system components in a preferred wireless communication system.

0029Fig. 7 is an abstract diagram illustrating the transfer of information to and from a particular network in accordance with the system components and interfaces of Fig. 6. Fig. 8 is a diagram of an embodiment of the Fig. 6 system architecture focusing on the base station interfaces.

0030Fig. 9 is a diagram illustrating a breakdown of software functionality within a base station. Fig. 10 is a diagram of an information packet in accordance with one embodiment of the present invention.

0031Fig. 11 is a diagram of an exemplary data frame for transmitting messages to and from a base station controller.

0032Fig. 12 is a diagram of an exemplary address field in the data packet of Fig. 11.

0033Fig. 13 is a diagram of a process for communicating signaling data among system components in a preferred mobile communication system.

0034Fig. 14 is a diagram of a particular I-interface architecture utilizing a shared memory element (i.e., dual-port RAM) , and Fig. 15 is a table of an exemplary dual-port RAM map.

0035Figs. 16A and 16B are a block diagrams of a base station showing separate controllers and interface components. Figs. 17A and 17B are exemplary dual-port RAM maps.

0036DESCRIPTION OF THE PREFERRED EMBODIMENTS Figure IA is a diagram of a pattern of cells in a wireless communication system 101 for communication among a plurality of user stations 102. The wireless communication system 101 of Fig. IA includes a plurality of cells 103, each with a base station 104, typically located at the center of the cell 103. Each station (both the base stations 104 and the user stations 102) generally comprises a receiver and a transmitter. In a preferred embodiment, a control station 105 (also comprising a receiver and a transmitter) manages the resources of the system 101. The control station 105 (sometimes referred herein as a "base station controller") may assign the base station 104 transmitters and user station 102 transmitters in each cell 103 a spread-spectrum code for modulating radio signal communication in that cell 103. The resulting signal is generally spread across a bandwidth exceeding the bandwidth necessary to transmit the data, hence the term "spread spectrum" . Accordingly, radio signals used in that cell 103 are spread across a bandwidth sufficiently wide that both base station 104 receivers and user station 102 receivers in an adjacent cell 103 may distinguish communication which originates in the first cell 103 from communication which originates in the adjacent cell 106. Figure IB is a block diagram of a communication system architecture utilized in a preferred embodiment of the present invention. The Fig. IB communication system comprises a plurality of base stations 104 for communicating with a plurality of user stations 102. The base stations 104 and user stations 102 may operate in a personal communications system

0037(PCS) , such as may be authorized under rules prescribed by the Federal Communications Commission (FCC) .

0038Each base station 104 may be coupled to a base station controller 105 by any of a variety of communication paths 109. The communication paths 109 may each comprise one or more communication links 118. Each communication link 118 may include a coaxial cable, a fiber optic cable, a digital radio link, or a telephone line.

0039Each base station controller 105 may also be connected to one or more communication networks 126, such as a public switched telephone network (PSTN) or personal communication system switching center (PCSC) . Each base station controller 105 is connected to a communication network 126 by means of one or more communication paths 108, each of which may include a coaxial cable, a fiber optic cable, a digital radio link, or a telephone line.

0040The Fig. IB communication system also may include one or more "intelligent" base stations 107 which connect directly to a communication network 126 without interfacing through a base station controller 105. The intelligent base stations 107 may therefore bypass the base station controllers 105 for local handoffs and switching of user stations 102, and instead perform these functions directly over the network 126. In terms of the interfaces described hereinafter (see Fig. 6) , an intelligent base station 107 does not require an N-Interface, and the functions of the base station controller 105 for transmitting to the network 126 are incorporated within the intelligent base station 107. In operation each base stations 104 formats and sends digital information to its respective base station controller 105 (or directly to the network 126 in the case of an intelligent base station 107) . The base station controllers 105 receive inputs from multiple base stations 104, assist handoffs between base stations 104, and convert and format channel information and signaling information for delivery to the network 126. The base station controllers 105 may also manage a local cache VLR database, and may support basic operation, administration and management functions such as billing, monitoring and testing. Each base station controller 105, under control of the network 126, may manage local registration and verification of its associated base station 104 and may provide updates to the network 126 regarding the status of the base stations 104.

0041The network 126 connects to the base station controllers 105 for call delivery and outgoing calls. Intelligent base stations 107 may use ISDN messaging for registration, call delivery and handoff over a public telephone switch. The intelligent base station 107 may have all the general capabilities of a base station 104 but further incorporate a BRI card, additional intelligence and local vocoding.

0042If the network 126 is a GSM network, then base stations 104 may connect to the network 126 through a defined

0043"A" interface. The "A" interface may be incorporated in base station controllers 105 and in intelligent base stations 107. Features and functionality of GSM may be passed to and from the base stations 104 over the "A" interface in a manner that is transparent to the end user.

0044The system may also interconnect to cable television distribution networks. The base stations 104 may be miniaturized so that they can be installed inside standard cable TV amplifier boxes. Interfacing may be carried out using analog remote antenna systems and digital transport mechanisms. For example, Tl and FT1 digital multiplexer outputs from the cable TV network may be used for interfacing, and basic rate (BRI) ISDN links may be used to transport digital channels. Figure IC is a diagram of a particular cellular environment in which the invention may operate. In Fig. IC, a geographical region 132 is divided into a plurality of cells 130. Associated with each cell 130 is an assigned frequency from among frequencies Fl, F2 and F3 , and an assigned spread spectrum code (or code group) from among the codes (or code groups) Cl, C2, C3, C4, C5 and C6. The three different frequencies Fl, F2 and F3 are preferably assigned in such a manner that no two adjacent cells 130 have the same assigned frequency Fl, F2 or F3, thereby resulting in minimization of interference between adjacent cells 130. The spread spectrum codes Cl through C6 are preferably orthogonal and may be assigned in adjacent clusters 131 such as shown in Fig. IC. Although six spread spectrum codes Cl through C6 are depicted in Fig. IC, other numbers of spread spectrum codes may be used depending upon the particular application.

0045Further details regarding an exemplary cellular pattern are described in, e.g., U.S. Patent No. 5,402,413, entitled "Three Cell Wireless Communication System, " which application is assigned to the assignee of the present invention, and is hereby incorporated by reference as if fully set forth herein.

0046Figure 2 is a block diagram of an exemplary transmitter and receiver in a spread spectrum communication system as may be employed for spreading and despreading signals in the communication system of Fig. IA. In Fig. 2, a spread- spectrum transmitter 201 comprises an input port 202 for input data 203, a chip sequence transmitter generator 204, a modulator 205, and a transmitting antenna 206 for transmitting a spread- spectrum signal 207. A spread-spectrum receiver 208 comprises a receiver antenna 209, a chip sequence receiver generator 210, a demodulator 211, and an output port 212 for output data 213. In operation, a single chip sequence 214 is identically generated by both the transmitter generator 204 and the receiver generator 210, and appears essentially random to others not knowing the spreading code upon which it is based. The spread-spectrum signal 207 is despread with demodulator 211 by correlating the received signal with a locally generated version of the chip sequence 214. Exemplary correlators are described in, e.g., U.S. Patent Nos. 5,022,047 and 5,016,255, each of which are assigned to the assignee of the present invention, and each of which are incorporated by reference as if fully set forth herein. A preferred method of correlation is described in U.S. Patent Application Serial No. 08/481,613 entitled "Multi-Bit

0047Correlation of Continuous Phase Modulated Signals, " filed June 7, 1995, hereby incorporated by reference as if set forth fully herein.

0048Spread spectrum communication techniques are further described in, e.g. , Robert C. Dixon, Spread Spectrum Systems with Commercial Applications (John Wiley & Sons, 3d ed. 1994) . Data may be transmitted between the base station 104 and user stations 102 using an M-ary spread spectrum technique. Suitable M-ary spread spectrum transmission and reception techniques are described in, e.g., U.S. Patent No. 5,022,047 and in U.S. Patent Application Serial No. 08/484,007 entitled "Method and Apparatus for Decoding a Phase Encoded Signal, " filed June 7, both of which are incorporated by reference as if set forth fully herein. In a preferred embodiment, the base station 104 and user stations 102 each transmit an M-ary direct sequence spread spectrum signal, with M=6, using spread spectrum codes (called "symbol codes") of 32 chips. Thirty-two different symbol codes are used to represent up to thirty-two different data symbols, each comprising five bits of data; phase encoding may also be used to allow transmission of a 6th bit of data for each symbol code. Techniques of phase encoding for transmission of an additional bit of information per symbol code are described in, e.g. , U.S. Patent Application Serial No. 08/484,007, referenced above. User stations 102 in one embodiment may comprise mobile handsets capable of multi-band and/or multi-mode operation. The user stations 102 may be multi-mode in that they may be capable of both spread spectrum (i.e. , wideband) communication and also narrowband communication. The user stations 102 may be multi-band in the sense that they may be set to operate on a plurality of different frequencies, such as frequencies in either the licensed or unlicensed PCS bands. The user stations 102 may operate in one mode (e.g. , wideband) over a first frequency band, and another mode (e.g., narrowband) over a second frequency band.

0049As an example, a user station 102 may be set to operate on a plurality of frequencies between 1850 and 1990 MHZ, with the frequencies separated in 625 kHz steps. Each user station 102 may be equipped with a frequency synthesizer that may be programmed to allow reception and/or transmission on any one of the plurality of frequencies. Further information regarding dual-mode and/or dual-band communication is set forth in U.S. Patent Application Serial No. 08/483,514 (attorney docket 214/071) entitled "Dual-Mode Wireless Unit with Two Spread Spectrum Frequency Bands," filed on June 7, 1995 in the name of inventors Robert C. Dixon et al.

0050Figure 3 is a diagram showing a timing structure for a particular TDMA system. According to the timing structure of Fig. 3, communication over time is broken into a continuous series of time frames 301. A single complete time frame 301 is shown along a timeline 310 in Fig. 3; similar time frames are assumed to precede and follow time frame 301 in a continuous pattern along the timeline 310.

0051Time frame 301 is divided into a plurality of time slots 302 numbered consecutively TSI, TS2...TSN, each of which may support duplex communication with a user station 102. Time frame 301 may be thought of as a "polling loop" or a time loop, as depicted in Fig. 3, whereby user stations 102 are communicated with sequentially over the time frame 301 in a manner analogous to polling, each user station 102 transmitting and receiving messages in its designated time slot 302. In the Fig. 3 embodiment, each time slot 302 comprises a user portion 305, wherein a user station 102 transmits a user-to-base message to the base station 104, and a base portion 306, wherein the base station 104 transmits a base-to-user message to the user station 102.

0052Time slots 302 define a set of transmission channels. Each transmission channel may further defined by a distinct frequency channel, a distinct spread spectrum code, a distinct spatial direction, or some combination thereof.

0053In an exemplary TDMA communication system, time frames 301 are each 20 milliseconds in duration, and each time frame 301 comprises sixteen time slots 302 or, alternatively, eight time slots 302 to support extended range through increased guard times. In a preferred embodiment, each time slot 302 is 1.25 milliseconds long. Each time slot 302 in such an embodiment comprises a total of 3125 chip periods, and base station transmissions sent during base portions 306 of the time slot 302 and user station transmissions sent during user portions 305 of the time slot 302 each have a chipping rate of 2.5 Megachips/ second. In some embodiments, a user station 102 may communicate in more than one time slot 302 in each time frame 301, so as to support an increased data rate. Similarly, in some embodiments, a user station 102 may periodically skip time frames 301 and communicate in some subset of all time frames 301 (e.g., every other time frame 301, or every fourth time frame 301) , so as to support a reduced data rate where a full speed communication link is not necessary. Further information about an exemplary TDMA system supporting variable data rates may be found in copending U.S. Patent Application Serial No. 08/284,053 filed August 1, 1994, which is hereby incorporated by reference as if fully set forth herein. An alternative over-the-air protocol is also described therein.

0054Figure 5A is a diagram of a preferred slot structure, and Figs. 5B and 5C are diagrams of a base station traffic message structure and a user station traffic message structure, respectively. In Fig. 5A, a time slot 510 comprises a variable radio delay gap 505, a user station transmit frame 515, a base processor gap 525, a guard time 535, a base station transmit frame 545, and a radar gap 555. Each user station transmit frame 515 comprises a user preamble 516, a user preamble sounding gap 519, and a user station data frame 521. Similarly, each base station transmit frame 545 comprises a base preamble 547, a base preamble sounding gap 549, and a base transmit data frame 551. Figure 5B illustrates a preferred message structure for the base transmit data frame 551. The message structure of Fig. 5B comprises a base header field 553, a base D-channel field 557, a base data field 559, and a base cyclical redundancy check (CRC) field 561. In a preferred embodiment, the base header field 553 is 23 bits, the base D-channel field 557 is 8 bits, the base data field 559 is 192 bits, and the base CRC field 561 is 16 bits.

0055Figure 5C illustrates a preferred message structure for the user station transmit data frame 521. The message structure of Fig. 5C comprises a user header field 523, a user D-channel field 527, a user data field 529, and a user CRC field 531. In a preferred embodiment, the user header field 523 is 17 bits, the user D-channel field 527 is 8 bits, the user data field 529 is 192 bits, and the user CRC field 531 is 16 bits.

0056Signaling messages (i.e., messages used for control traffic) may be used to assist in acquisition and maintenance of a channel from the network. A message may include a message type data element located in a message type field. The message type data element defines the format of the rest of the message, and acts as an operation code to the destination unit (either user station 102 or base station 104) . Exemplary message types (and their abbreviations) appear in Table 1 below.

0057Table 1

0058Message Type Message

0059ACK Acknowledge

0060AUT Authentication Request

0061AUR Authentication Response BAI Base Assist Information

0062BAR Base Assist Request

0063CIP Set Cipher Mode

0064CNC Call Connected

0065CNL Connect Link CSC Circuit Switch Complete

0066DRG De-registration Request

0067HLD Hold

0068HOF Handover Failed

0069MAI User Station Assist Information MAR User Station Assist Request

0070OHC Originating Handover Complete ORH Originating Handover Request ORG Originate Call RCP Registration Complete REL Release Link Q Registration Request SPR Specific Response STL Set Link SYN Synchronize THC Terminating Handover Complete THR Target handover Request TRA Transport Message with TCID

0071The message type data element may be, e.g., 8 bits in length. Figure 6 is a diagram of various system components within a preferred wireless communication system showing interfaces between the components. Four distinct interfaces are defined in the Fig. 6 system, labeled "M", "0", "I", and "N" , and are referred to herein as the M-Interface 605, O-Interface 610, I-Interface 615, and N-Interface 620, respectively. The M-Interface 605 may be internal to a user station

0072102 and generally defines a boundary between an application end user 602 and a mobile communication transceiver 603 in the user station 102. The O-Interface 610 generally comprises communication channel (typically an over-the-air communication channel) between the mobile communication transceiver 603 in the user station 102 and a base station transceiver 604. The I- Interface 615 may be thought of as "internal" to a base station 104 and generally defines a boundary between the base station transceiver 604 and a base station line card processor 606. Finally, the N-Interface 620 comprises an information channel 607 between the line card processor 606 and a base station controller 609 (such as, e.g., base station controller 105 shown in Fig. IB) .

0073Within the communication system 101, information is communicated across each interface 605, 610, 615, and 620 according to a particular protocol governing exchange of information across that interface. Thus, a total of four protocols are defined, one for each interface 605, 610, 615, 620. A fifth protocol may be defined for an adaptation layer interface (e.g., the GSM "A" interface) at the base station controller 105.

0074In a preferred embodiment, the communication system 101 communicates both user data and signaling data across one or more of the system component interfaces under the same or similar protocols. User data (also referred to as bearer data) comprises, in general, data which originates at the application end user and is passed to the communication system across an adaptation layer interface. User data may include voice, error- controlled data, or non-error controlled (raw) data. Signaling data (also called control data) , on the other hand, generally comprises information exchanged within the communication system, or between the communication system and application end users, for the purpose of service connection (i.e., connection establishment and maintenance) .

0075The mobile communication system 101 transfers information across one or more system interfaces through a series of packetized messages referred to as "Notes". Each Note may contain data intended for receipt by an application end user (user data) or data to be used for link establishment and maintenance (signaling data), or both. Each interface 605, 610, 615, 620 communicates with Notes formatted according to a particular protocol specific to the interface.

0076The mobile communication system 101 transfers information comprising signaling data and user data between a base station 104 (i.e., the base station transceiver 604) and a user station 102 (i.e., the mobile station transceiver 603) across the 0-Interface 610. In a preferred embodiment, the O- Interface 610 operates according to an over-the-air protocol with time division duplexing (TDD) and time division multiple access (TDMA) techniques. A preferred protocol for the 0- Interface 610 is shown in and described with respect to Fig. 3.

0077Signaling data is passed across the O-Interface 610 in the form of messages referred to as "O-Notes" . In a preferred embodiment, the O-Notes are contained either within the base data field 559 (see Fig. 5B) or the user data field 529 (see Fig. 5C) , depending upon the origin of the message. Alternatively, an O-Note may be segmented into, e.g., 8-bit segments and transmitted over a plurality of time slots 302 in US9 /151

007817 the D-field 557 of the base message (see Fig. 5B) or the D-field 527 of the user message (see Fig. 5C) . Generally, lower priority O-Note messages may be segmented and transmitted in the D-fields 557 or 527, while higher priority O-Note messages may be transmitted in the B-fields 579 or 529. Also, O-Notes may be transmitted in the B-field 579 or 529 when it is not otherwise being used (e.g., when the link is first being established and voice data is not being transferred yet) .

0079A field or flag in the header of a base message or user message can be used to indicate whether an O-Note is contained in the B-field 579 or 529, or in the D-field 557 or 527. In some circumstances, an extended O-Note may be sent in a message covering both the D-field and the B-field.

0080Figure 10 is a diagram of an information packet 1005 (e.g., the base message of Fig. 5B or the user message of Fig. 5C) which may be passed across the 0-Interface 610. An O-Note 1010 is encapsulated within the packet 1005, and resides in the data field 529, 559 ordinarily reserved for bearer traffic. Each information packet 1005 generally also comprises a header 1015 of, e.g., 24 bits, a D-field of, e.g., 8 bits, and a frame check word 1020 of, e.g., 16 bits, for a total of 240 bits. In a preferred embodiment, each O-Note 1010 has a length of no more than 160 bits, thereby taking up less space than the entire B-field 529 or 569 The latter 32 bits of the 0- Note 1010 (appended to the first 160 bits) may be used for forward error correction.

0081Table 2-1 through Table 2-33 illustrate exemplary O- Notes 1010 which may be transferred across the O-Interface 610 in a preferred embodiment of the communication system 101. In Table 2-1 through Table 2-33, a mobile communication transceiver 603 may be denoted "MS-OTA" and a base station transceiver 604 may be denoted "BS-OTA. " Table 2-1 CT-ACK (Acknowledge) [MS-OTA <=> BS-OTA]

0082Information Element Length in Bits

0083Command Type 8

0084ACK Response 8

0085ACK' ed Command 8

0086Cause 8

0087Reserved 128

0088< Total Bi ts In MSG> 160

0089Acknowledge messages can be transmitted by either the BS-OTA or the mobile communication transceiver 603. They are usually the last element of a larger signaling exchange.

0090Table 2-2 CT-ASI (Assist Information) [MS-OTA <=> BS-OTA]

0091Information Element Length in Bits

0092Message Type 8

0093Assist Type 8

0094Assist Data 144

0095<Total Bits in MSG> 160

0096This message is sent either from the BS-OTA to the mobile communication transceiver 603 or from the mobile communication transceiver 603 to the BS-OTA. It provides a mechanism to impart various items of information to assist the recipient in making well formed decisions. It may be sent in response to a CT-ASR message or it may be unsolicited. Table 2 -3 CT-ASR (Assist Request) [MS-OTA <=> BS-OTA]

0097Information Element Length in Bits

0098Message Type 8

0099Assist Type 8

0100Assist Request Info 144

0101< To tai Bi ts In MSG> 160

0102This message is sent either from the BS-OTA to the mobile communication transceiver 603 or from the mobile communication transceiver 603 to the BS-OTA to request information. It provides a mechanism for the sender to request various items of information to assist it making well informed decisions.

0103Table 2-4 CT-AUR (Authentication Reject) [MS-OTA <=> BS-OTA]

0104Information Element Length in Bits

0105Message Type 8

TCID 8

0107Cause 8

0108Reserved 136

0109< Total Bi ts In MSG> 160

0110This message shall be sent to the mobile communication transceiver 603 from the BS-OTA to inform the mobile communication transceiver 603 that the Network Application has rejected its Authentication Response. Table 2-5 CT-AUR (Authentication Response) [MS-OTA _<=_> BS-OTA]

0111Information Element Length in Bits

0112Message Type 8

TCID 8

0114Authentication Test 128 Response

0115Reserved 16

0116< Total Bi ts In MSG> 160

0117The authentication response message shall be the mobile communication transceiver 603 response to an authentication challenge. It shall contain the results of encrypting the test number supplied by the authenticate message using the secret unique mobile user station traffic key.

0118Table 2-6 CT-AUT (Authentication Challenge) [MS-OTA &lt;= BS-OTA]

0119Information Element Length in Bits

0120Message Type 8

TCID 8

0122Cipher Type 8

0123Cipher Key Sequence # 8

0124Authentication Test 128 Number

0125< Total Bi tε In MSG> 160

0126This message shall be sent to the mobile communication transceiver 603 from the BS-OTA whenever the BS starts an authentication sequence. This message shall supply a 128 bit challenge number to be used by the mobile user station 102 using the unique secret mobile user station traffic key to generate the authentication response message. Table 2-7 CT-AUG (Authentication Rejection) [MS-OTA &lt;= BS-OTA]

0127Information Element Length in Bits

0128Message Type 8

TCID 8

0130Cause 8

0131Reserved 136

0132<Total Bi ts In MSG> 160

0133This message shall be sent to the mobile communication transceiver 603 from the BS-OTA whenever the communication system 101 rejects an Authentication Response from the mobile communication transceiver 603.

0134Table 2-8 CT-CIP (Set Cipher Mode) [MS-OTA &lt;= BS-OTA]

0135Information Element Length in Bits

0136Message Type 8

0137Cipher Algorithm ID 8

0138Frame Number 24

0139Frame Offset 8

0140Cause 8

0141Request PID Type 8

0142Reserved 88

0143<Total Bits In MSG> 152

0144This message is sent to the mobile communication transceiver 603 from the BS-OTA whenever the base station 104 wishes the mobile communication transceiver 603 to switch to cipher mode. When the mobile communication transceiver 603 receives this message the mobile communication transceiver 603 uses the cipher mode parameters to set its ciphering equipment and then switches into or out of cipher mode. All traffic after this point will be ciphered. Table 2- 9 CT-CNC (Connection Complete) [MS-OTA &lt;= BS-OTA]

0145<img file="WO9713353A1_D0001.tif" />

0146<Total Bi ts In MSG> 160

0147The CT-CNC message is set from the terminating base station 104 to the mobile communication transceiver 603 when a handover is completed.

0148Table 2-10 CT-CSC (Circuit Switch Complete) [MS-OTA &lt;= BS-OTA]

0149Information Element Length in Bits

0150Message Type 8

0151(New) Zone 40

0152(New) Base ID 32

0153HRef 48

0154Reserved 32

0155< Total Bi ts In MSG> 160

0156This message is set from the source base station 104 to the mobile communication transceiver 603 to signal that the communication system connection is available at the target base station 104. Table 2-11 CT-DRG (De-registration) [MS-OTA => BS-OTA]

0157Information Element Length in Bits

0158Message Type 8

0159Cause 8

0160Reserved 144

0161< Total Bi ts In MSG> 160

0162The mobile communication transceiver 603 shall send a de-registration message to the BS-OTA when the mobile communication transceiver 603 de-registers itself from the base station 104. If the mobile communication transceiver 603 does not send this message, de-registration shall automatically occur a fixed time-out period (e.g., 30 seconds) from the last time the mobile communication transceiver 603 sent a registration request to the base station 104.

0163Table 2-12 CT-HLD (Hold) [MS-OTA <=> BS-OTA]

0164<img file="WO9713353A1_D0002.tif" />

0165< Total Bi ts In MSG> 160

0166Table 2-13 CT-GPO (General Poll) [MS <==> BS]

0167The BS broadcasts a CT-GPO when it has channels available. The CT-GPO is a general invitation to any MS to attempt to seize a TDD channel (time slot) . This poll indicates a free channel (time slot) . Information Element Length in Bits

0168Message Type 8

0169Zone 40

BSC ID 16

0171Base ID 32

0172BS Capabilities 32

0173System Type 8

0174Service Provider 16

0175Slot Quality 8

0176<Total Bits In MSG> 160

0177Table 2-14 CT-GPR (General Poll Response) [MS <==> BS]

0178The MS shall send a CT-GPR message to the BS in response to a CT-GPO when the MS wishes to acquire a link to the BS

0179Information Element Length in Bits

0180Message Type 8

0181Transaction Hint 8

0182Transaction Hint 8 Qualifier

PID 72

0184Service Provider 16

0185Class 16

0186MS Capabilities 16

0187Reserved 16

0188< Total Bi ts In MSG> 160

0189Hold packets can be transmitted by either the BS-OTA or the mobile communication transceiver 603. They are always part of a larger signaling traffic exchange and are used to maintain the communication link across the 0-Interface 610 while waiting for an external event . Table 2-15 CT-HOF (Handover Failure) [MS <==> BS]

0190This message is sent to the MS by either the Originating BS or the Terminating BS to indicate to the MS that the requested handover (OHR or THR) has failed.

0191Information Element Length in Bits

0192Message Type 8

0193Cause 8

0194Reserved 144

0195< Total Bi ts In MSG> 160

0196Table 2-16 CT-IRP (Identity Reply) [MS-OTA => BS-OTA]

0197Information Element Length in Bits

0198Message Type 8

0199Identity Type 8

0200Identity Data 72

0201Message Sequence 8 Number

0202Reserved 64

0203< Total Bi ts In MSG> 160

0204The mobile communication transceiver 603 sends a CT- IRP message to the BS-OTA in response to a CT-IRQ message. Table 2 - 17 CT- IRQ ( Identity Request ) [MS-OTA &lt;= BS-OTA]

0205Information Element Length in Bits

0206Message Type 8

0207Identity Type 8

0208Reserved 144

0209<Total Bi ts In MSG> 160

0210The BS-OTA sends a CT-IRQ message to the mobile communication transceiver 603 when it receives an Identity Request Note from an application end user connected to a base station controller 105. This allows the application end user to obtain one of the mobile user station's Identifiers that is not normally included in the protocol.

0211Table 2-18

0212CT-OHC (Originating Handover Complete)

0213[MS-OTA => Target BS-OTA]

0214Information Element Length in Bits

0215Message Type 8

0216HRef 8

PID 72

0218Registration Type 8

0219Registration Status 8

0220Reserved 16

0221<Total Bi ts In MSG> 160

0222The Originating Handover Complete message is sent from the mobile communication transceiver 603 to the target (new) base station to complete the Originating Handover procedure. Table 2 -19

0223CT-OHR (Originating Handover Request)

0224[MS-OTA => Originating BS-OTA]

0225Information Element Length in Bits

0226Message Type 8

0227(New) Zone 40

0228(New) BSC ID 16

0229(New) Base ID 8

0230Remaining Base 8 Count

0231Reserved 56

0232< Total Bi ts In MSG> 160

0233Originating Handovers will be attempted in cases when supporting a system such as DCS1900, where a terminating handover is not possible because there is no way the new base station controller 105 can notify the old base station controller 105 that the handover is required. The Originating Handover Request message is sent from the mobile communication transceiver 603 to the source BS-OTA to initiate the originating handover procedure.

0234Table 2-20

0235CT-PPR (Paging Poll Response) [MS-OTA <==> BS-OTA]

0236The MS send the CT-PPR message to the BS in response to a CT-PPRO from the BS.

0237Information Element Length in Bits

0238Message Type 8

PID 72

0240Service Provider 16

0241Class 16

0242MS Capabilities 16

0243Cipher Key 8 Sequence #

0244Reserved 24

0245<Total Bi ts In MSG> 160

0246Table 2-21 CT-RCP (Registration Complete) [MS-OTA <==> BS-OTA]

0247Upon initial or periodic registration completion, the BS responds to the MS with a registration complete message.

0248Information Element Length in Bits

0249Message Type 8

0250Registration Status 8

0251Registration Timers 8

0252Cause 8

0253Registration Result 8 Code

SBT 120

0255< Total Bi ts In MSG> 160

0256Table 2 -22 CT-REL (Release Link) [MS-OTA <=> BS-OTA]

0257Information Element Length in Bits

0258Message Type 8

0259Cause 8

0260Reserved 144 This message is sent by either the mobile communication transceiver 603 or the BS-OTA when the sending side released the connection in progress or during link setup

0261Table 2-23 CT-RRQ (Registration Request) [MS-OTA => BS-OTA]

0262Information Element Length in Bits

0263Message Type 8

0264Cipher Key 8 Sequence #

0265Registration Type 24

0266Registration Status 8

0267Registration Info 128

0268< Total Bi ts In MSG> 160

0269A registration request shall be sent from a mobile communication transceiver 603 to a BS-OTA on an initial and a periodic basis. Upon the initial request, the base station 104 shall enter the registration process. If the base station does not receive a periodic (30 seconds or as determined by the service provider) registration request from a mobile communication transceiver 603 which is currently registered with the base station, then the base station will initiate a de- registration procedure.

0270Table 2-24 CT-SPO (Specific Poll) [MS-OTA <==> BS-OTA] The CT-SPO is an invitation for only the MS identified by the PID Information Element to seize the indicated TDD channel (time slot) . It is generated by the BS in response to the Mobile Station's request to establish a link. <img file="WO9713353A1_D0003.tif" />

0271< Total Bi ts In MSG> 160

0272The mobile communication transceiver 603 sends the CT- SPR message to the BS-OTA in response to an unsolicited Specific Poll (i.e., one that is not part of link acquisition) . This occurs when the base station 104 wishes to initiate a transaction (e.g., incoming call or special operation) .

0273Table 2-25 CT-SRQ (Service Response) [MS-OTA => BS-OTA]

0274Information Element Length in Bits

0275Message Type 8

TCID 8

0277Resource Request 16 Data

0278Network Service 128 Reserved Data

0279< Total Bi ts In MSG> 160

0280The mobile communication transceiver 603 sends the service request message to the BS-OTA to request call management access to the communication system 101. Table 2-26 CT-SRS (Service Response) [MS-OTA <==> BS-OTA]

0281The BS sends the CT-SRS message to the MS to inform the MS of the network's response to a Service Request.

0282Information Element Length in Bits

0283Message Type 8

TCID 8

0285Network Service 24 Response

0286Cause 8

0287Reserved 112

0288< Total Bi ts In MSG> 160

0289Table 2-27.1 CT-STL (Set Link) [BS-OTA => MS-OTA]

0290<img file="WO9713353A1_D0004.tif" />

0291<Total Bi ts In MSG> 160

0292The BS-OTA sends the STL message to the mobile communication transceiver 603 when the BS-OTA wishes to change the characteristics of the over the air service across the O- Interface 610. Table 2 -27.2 CT-STL (Set Link) [MS-OTA => BS-OTA]

0293<img file="WO9713353A1_D0005.tif" />

0294< Total Bi tε In MSG> 160

0295The mobile communication transceiver 603 sends the CT-

0296STL message to the BS-OTA when the mobile user station wishes to change the characteristics of the over the air service across the 0-Interface 610.

0297Table 2-28 CT-SYN (Synchronize) [MS-OTA <=> BS-OTA]

0298Information Element Length in Bits

0299Message Type 8

0300Cipher Algorithm ID 8

0301Cipher Key 8 Sequence #

0302Frame Number 24

0303Frame Offset 8

0304Cause 8

0305Reserved 96

0306< Total Bi tε In MSG> 160

0307Synchronize messages can be transmitted by either the

0308BS-OTA or the mobile communication transceiver 603. They are always part of recovery from an error in a signaling transaction , They are initiated by whichever side discovered the error .

0309Table 2-29 CT-THC (Terminating Handover Complete) [MS-OTA => Target BS-OTA]

0310Information Element Length in Bits

0311Message Type 8

0312Registration Type 8

0313Registration Status 8

0314Reserved 136

0315<Total Bi ts In MΞG> 160

0316The terminating Handover Complete message is sent from the mobile communication transceiver 603 to the target (new) base station to complete the Terminating Handover procedure.

0317Table 2-30 CT-THR (Terminating Handover Request) [MS-OTA => Target BS-OTA]

0318Information Element Length in Bits

0319Message Type 8

0320Resource Request 16

0321(Old) Zone 40

0322(Old) BSC ID 16

0323(Old) BS ID 32

0324(Old) Connection 24 Number

0325Reserved 24

0326<Total Bi ts In MSG> 160

0327Handovers can, with certain limitations, be initiated either from the old base station 104 (an originating handover) or the new base station 104 (a terminating handover) . The mobile communication transceiver 603 will attempt a terminating handover whenever possible because they are faster and more robust . The Terminating Handover Request message is sent from the mobile communication transceiver 603 to the target BS-OTA to initiate the terminating handover procedure.

0328Table 2-31 CT-TRA (Transport Message) [MS-OTA <=> BS-OTA]

0329Information Element Length in Bits

0330Message Type 8

0331Transport Data 152

0332< Total Bi ts In MSG> 160

0333The Transport Data includes the New Personal ID, Message Sequence number, and reserved bits, as below.

0334Information Element Length in Bits

0335Message Type 8

0336New Personal ID 72

0337Message Sequence 8 Number

0338Reserved 72

0339< Total Bi ts In MSG> 160

0340The Transport message transports bearer or user data between the BS-OTA and mobile communication transceiver 603 on the circuit specified by TCID (part of the Message Type for CT- TRA Notes) . Table 2-32 CT-TSI (Time Slot Interchange) [MS-OTA => BS-OTA]

0341Information Element Length in Bits

0342Message Type 8

0343Reserved 152

0344A Time Slot Interchange request shall be sent from a mobile communication transceiver 603 to a BS-OTA when the mobile communication transceiver 603 determines that its signal quality might improve if it were communicating with the BS-OTA on different time slot(s) . The BS-OTA will respond with a CT-STL message, giving the mobile communication transceiver 603 a different time slot map, if it can accommodate the TSI request. If the BS-OTA cannot accommodate the TSI request it will respond with a CT-HOF message.

0345Table 2-33 CT-UID (Update ID) [MS-OTA &lt;= BS-OTA]

0346Information Element Length in Bits

0347Message Type 8

0348New Personal ID 72

0349Zone 40

0350Reserved 40

0351<Total Bi ts In MSG> 160

0352Upon receipt of an Update ID N-Note from a base station controller 105, the base station 104 sends the mobile user station 102 a CT-UID message.

0353The mobile communication system 101 transfers information in the form of signaling data and user data between a base station 104 and a base station controller 105 across an N-Interface 620. In a preferred embodiment, the N-Interface 620 comprises one or more 64 kbps DS0 lines between the base station 104 and base station controller 105. In a presently preferred embodiment, a base station 104 and base station controller 105 communicate signaling data across a single dedicated 64 kbps DSO line, while user data is communicated across one or more separate 64 kbps DSO lines. Each DSO line operates according to the same protocol for the N-Interface 620. Signaling data is communicated across the N-Interface

0354620 according to a protocol described in CCITT Recommendation Q.920/Q.921 called "Link Access Procedures on the D-channel ("LAPD") . LAPD is a subset of the ISO standard protocol High- level Data Link Control ("HDLC") . Further information regarding the LAPD protocol may be found in the CCITT IX Plenary Assembly Recommendations ("CCITT Blue Book") , Vol. VI, pp. 19-60, which is incorporated by reference as if set forth fully herein.

0355Signaling data information is transferred over the N- Interface 620 in the form of N-Notes . Figure 11 is a diagram of a preferred format for a data frame 1105 which may be passed across the N-Interface 620 in the communication system 101. Each N-Note 1110 is encapsulated within a data frame 1105.

0356Each data frame 1105 generally begins with an opening flag 1115 and ends with a closing flag 1120. The opening flag 1115 and closing flag 1120 each comprise a predefined bit sequence (e.g., "01111110") which signals the beginning and end of a data frame 1105. A system component sending data across the N-Interface 620 examines the frame content between the opening flag 1115 and closing flag 1120, and inserts a 0-bit after all sequences of five consecutive 1-bits. A system component receiving data across the N-Interface 620 discards any 0-bit which directly follows five consecutive 1-bits.

0357The opening flag 1115 is immediately followed by an address field 1125 comprising, e.g., 16 bits. Figure 12 is a diagram of a preferred address field 1125 format. In the Fig.

035812 embodiment, the address field 1125 comprises a Service Access Point Identifier (SAPI) subfield 1210 comprising, e.g., 6 bits, a command/response (C/R) bit 1215, and a terminal endpoint identifier (TEI) subfield 1220 comprising, e.g., 7 bits. The address field 1125 also has two extension address (EA) bits

03591225, one in the first address field octet having a value of 0, and the second in the second address field octet having a value of 1. The SAPI subfield 1210 identifies a protocol under which the current data frame 1105 operates. In one aspect, the SAPI subfield 1210 specifies an upper layer software entity for which the data carried by the current data frame 1105 is formatted. In a preferred embodiment, the N-Interface protocol may be specified by a SAPI subfield 1210 having a predefined value.

0360The TEI subfield 1220 identifies a specific terminal endpoint which is the destination for the current data frame 1105. Since the Q.921 link across the N-Interface 620 is actually a simple point-to-point connection between a base station 104 and a base station controller 105, only one TEI needs to be assigned to each physical interface in the mobile communication system 101. In a preferred embodiment, a unique TEI value is stored in each base station 104 and used during system initialization.

0361The address field 1125 is followed by a control field 1130 which identifies the type of frame as a command or response frame. The control field may be either a numbered information transfer (I) , an unnumbered information transfer (U) , or a supervisory frame (S) .

0362The control field 1130 is followed by an information field 1135 which contains an N-Note 1110. The information field 1135 is followed by a frame check sequence 1140 comprising two eight-bit bytes.

0363Table 3-1 through Table 3-39 describe exemplary N- Notes which may be communicated across the N-Interface 620 in a preferred embodiment of the communication system 101. In Table 3-1 through Table 3-39, a base station 104 is denoted "BS" and a base station controller 105 is denoted "BSC." Table 3-1 Assist Information [BS <=> BSC]

0364Information Element Length in Octets

0365Protocol 1

0366System Type 1

0367Message Type 1

0368Assist Type 1

0369Assist Data 18

0370This message is sent either from the base station 104 to the base station controller 105 or from the base station controller 105 to the base station 104. It provides a mechanism to impart various items of information to assist the recipient in making well informed decisions.

0371Table 3-2 Assist Request [BS <=> BSC]

0372Information Element Length in Octets

0373Protocol 1

0374System Type 1

0375Message Type 1

0376Channel Preference 1

0377Assist Type 1

0378Assist Request Info 18

0379This message is sent either from the base station 104 to the base station controller 105 or from the base station controller 105 to the base station 104 to request information. It provides a mechanism for the sender to request various items of information to assist in making well informed decisions. Table 3-3 Authenticate [BS &lt;= BSC]

0380Information Element Length in Octets

0381Protocol 1

0382System Type 1

0383Message Type 1

PID 9

TCID 1

0386Cipher Key Sequence # 1

0387Authentication Test 16 Number

0388The Authenticate N-Note is sent to the base station 104 from the network 126 to request that the base station 104 send to the mobile user station 102 in an Authenticate O-Note. The mobile user station 102 will then encrypt the "random" number using the authentication key provisioned into the mobile station 102 and send this encrypted number back to the base station 104 in an Authentication Response Message (CT-AUR) reply. The base station 104 then sends this result to the network 126 in an Authentication Reply N-Note.

0389Table 3-4 Authenticate Reply [BS => BSC]

0390Information Element Length in Octets

0391Protocol 1

0392System Type 1

0393Message Type 1

PID 9

0395Authentication Test 16 Response

0396The Authenticate Reply N-Note from the base station 104 to the network 126 is triggered by an Authentication Response O-Note (CT-AUR) from the mobile user station 102. The Authenticate Reply N-Note communicates a sixteen octet encrypted response from the mobile user station 102 to the network 126 for confirmation. The network 126 will perform encryption on the original random number and compare the results for authentication. The Authenticate Reply should be the response to an earlier Authenticate N-Note issued for the given PID by the network 126. If the return value is incorrect, the proper response of the network 126 is to deny access by the mobile user station 102.

0397Table 3 -5 Authentication Reject [BS &lt;= BSC]

0398Information Element Length in Octets

0399Protocol 1

0400System Type 1

0401Message Type 1

PID 9

TCID 1

0404Cause 1

0405The Authentication Reject N-Note is sent to the base station 104 from the network 126 to inform the mobile user station 102 that the network 126 has rejected its Authenticate Reply.

0406Table 3-6 Base Status Request [BS &lt;= BSC]

0407Information Element Length in Octets

0408Protocol 1

0409System Type 1

0410Message Type 1

PID 9

CI 1

0413Base ID 4

0414Base Status 32 The Base Status Request N-Note is sent to the base station 104 by the network 126 to initiate a Base Status Response N-Note from the base station 104.

0415Table 3-7 Base Status Response [BS => BSC]

0416Information Element Length in Octets

0417Protocol 1

0418System Type 1

0419Message Type 1

PID 9

0421Base ID 32

0422The Base Status Response N-Note is sent to the network 126 by the base station 104 after receiving a Base Status Request N-Note from the network 126.

0423Table 3-8 Cipher Response [BS => BSC]

0424Information Element Length in Octets

0425Protocol 1

0426System Type 1

0427Message Type 1

PID 9

0429Cause 2

0430The Cipher Response N-Note is sent to the network 126 to inform it that the base station 104 and mobile user station 102 have configured and keyed their encryption equipment and have enabled the equipment . Table 3-9 Circuit Switch Complete [BS &lt;= BSC]

0431Information Element Length in Octets

0432Protocol 1

0433System Type 1

0434Message Type 1

PID 9

0436(New) Zone 5

0437(New) Base ID 4

0438HRef 6

0439The Circuit Switch Complete N-Note is sent to the originating base station 104 from the network 126 when a handover circuit switch operation has completed. This message informs the originating base station 104 that the bearer channel has been switched from the originating base station 104 to the terminating base station 104 and that the originating base station 104 may release all the resources associated with the mobile user station 102.

0440Table 3-10 Circuit Switch Refused [BS => BSC]

0441Information Element Length in Octets

0442Protocol 1

0443System Type 1

0444Message Type 1

PID 9

0446(New) Zone 5

0447(New) Base ID 4

0448HRef 6

0449The Circuit Switch Refused N-Note is sent to the network 126 from the originating base station 104 when the mobile user station 102 has rejected the circuit switch. Table 3-11 Connect Link [BS => BSC]

0450Information Element Length in Octets

0451Protocol 1

0452System Type 1

0453Message Type 1

PID 9

TCID 1

0456The Connect Link N-Note is sent from the base station 104 to the network 126 as the result of a CT-CNL message received from an mobile user station 102 while the base station 104 and mobile user station 102 are in a HOLD sequence initiated during an incoming call. The CT-ACK control traffic will be returned from the mobile user station 102. This message informs the network 126 that it may complete the connection with the calling station.

0457Table 3-12 Connect Link [BS &lt;= BSC]

0458Information Element Length in Octets

0459Protocol 1

0460System Type 1

0461Message Type 1

PID 9

TCID 1

0464Connection Number 3

0465Cause 1

0466The Connect Link N-Note is sent to the base station 104 from the network 126 when a connection has been made to another station via the network 126. This message associates the PID of an mobile user station 102 with a Connection Number, Table 3-13 Connection Complete [BS &lt;= BSC]

0467Information Element Length in Octets

0468Protocol 1

0469System Type 1

0470Message Type 1

PID 9

TCID 1

0473Cipher Algorithm ID 1

0474Cipher Key 8

0475Connection Number 3

0476The Connection Complete N-Note is sent to the termination base station 104 from the network 126 when a handover circuit switch operation has completed. This message informs the terminating base station 104 that the bearer channel has been switched from the originating base station 104 to the terminating base station 104.

0477Table 3-14 Deregister [BS => BSC]

0478Information Element Length in Octets

0479Protocol 1

0480System Type 1

0481Message Type 1

PID 9

0483Class 2

0484Cause 1

0485The Deregister N-Note is issued from the base station 104 to the network 126 as the result of either a DRG control traffic response message or a base station time-out, which indicates that the identified mobile user station 102 is no longer in the response range of the base station 104. The proper response of the network 126 is to release all resources which may have been preallocated to the mobile user station 102 Table 3-15 Handover Failure [BS &lt;= BSC]

0486Information Element Length in Octets

0487Protocol 1

0488System Type 1

0489Message Type 1

PID 9

0491Cause 1

0492The Handover Failed N-Note is sent to both the source and target base stations 104 from the network 126 when the higher order network infrastructure has rejected the terminating or originating handover request from the mobile user station 102. Each base station must send a CT-HOF O-Note to the mobile user station 102 if/when it communicates with the mobile user station 102. The source base station 104 will maintain the existing connection to the mobile user station 102; the target base station 104 will release the connection with the mobile user station 102 after sending the CT-HOF.

0493Table 3-16 Handover Request [BS &lt;= BSC]

0494Information Element Length in Octets

0495Protocol 1

0496System Type 1

0497Message Type 1

0498PID (HRef) 9

CI 1

TCID 4

0501Connection Number 3

0502Cipher Algorithm ID 1

0503Cipher Key 8

0504Resource Request 2 Data

0505Transport Method 4 The Handover Request N-Note is sent to the target base stations from the base station controller when the higher order network infrastructure is attempting to perform an originating handover request from the mobile user station 102. The target base station 104 will reserve the requisite resources for the circuit being handed over, if available, and will respond to the base station controller 105 with a Handover Request ACK message.

0506Table 3-17 Handover Request Reply [BS => BSC]

0507Information Element Length in Octets

0508Protocol 1

0509System Type 1

0510Message Type 1

0511PID (HRef) 9

CI 1

0513Backhaul Map Type 1

0514Backhaul Map 4

0515Cause 1

0516The Handover Request Reply N-Note is sent to the base station controller 105 in response to the Handover Request message.

0517Table 3-18 ID Updated [BS <=> BSC]

0518Information Element Length in Octets

0519Protocol 1

0520System Type 1

0521Message Type 1

PID 9

0523Cause 1 The ID Updated N-Note is sent by the base station 104 to the network 126 to indicate the successful updating of an mobile user station PID.

0524Table 3-19 Identity Reply [BS => BSC]

0525Information Element Length in Octets

0526Protocol 1

0527System Type 1

0528Message Type 1

PID 9

CI 1

0531Identity Type 1

0532Identity Data 9

0533Message Sequence 1 Number

0534The Identity Reply N-Note is sent by the base station 104 to the network 126 to provide the mobile user station's requested identity.

0535Table 3-20 Identity Request [BS &lt;= BSC]

0536Information Element Length in Octets

0537Protocol 1

0538System Type 1

0539Message Type 1

PID 9

CI 1

0542Identity Type 1

0543The ID Updated N-Note is sent by the network 126 to the base station 104 to request a mobile user station identifier that has not been provided as part of the mobile user station's normal communications with the network 126. Table 3-21 Originating Handover [BS => BSC]

0544Information Element Length in Octets

0545Protocol 1

0546System Type 1

0547Message Type 1

PID 9

CI 1

0550Remaining Base 1 Count

0551(New) Zone 5

0552(New) BSC ID 2

0553(New) Base ID 4

0554The Originating Handover N-Note is sent from the base station 104 to the network 126 after an mobile user station 102 has returned to the originating base station 104 and has completed the originating handover control traffic sequence. This message contains the PID of the mobile user station 102, the base station ID and Zone of the terminating base station 104. This information is to be used by the network 126 to establish a bearer connection to the terminating base station 104. The network 126 should respond to the originating base station 104 with a Circuit Switch Complete N-Note signifying that the terminating base station 104 is now connected to the proper bearer channel.

0555Provision is made for this message to provide a list of base stations 104 the mobile user station 102 is willing to handover to. This allows the potential ability for the mobile user station 102 to signal the base station 104, as part of the CT-OTH message, that there are several acceptable alternatives and to send each of them to the originating base station 104 as sequential CT-OTH messages. The base station 104 may accumulate the acceptable base station list and send it to the base station controller 105 in a single message. The Count Base field lists the number of base stations 104 in the list. Table 3-22 Originating Handover Complete [BS => BSC]

0556Information Element Length in Octets

0557Protocol 1

0558System Type 1

0559Message Type 1

0560PID (HRef) 9

CI 1

0562PID (Real) 9

0563The Originating Handover Complete N-Note is issued from the terminating base station 104 to the terminating application end user (e.g., network 126) connected to the base station controller 105 when a mobile user station 102 has completed its transfer of its bearer traffic from the originating base station 104 to the terminating base station 104. This happens when the mobile user station 102 issues a Originating Handover Complete control traffic message to the terminating base station 104.

0564Table 3-23 Page [BS &lt;= BSC]

0565Information Element Length in Octets

0566Protocol 1

0567System Type 1

0568Message Type 1

PID 9

CI 1

TCID 1

0572The Page N-Note is sent to the base station 104 from the network 126 to notify the base station 104 of an incoming call The base station 104 should initiate a Specific Poll sequence for the mobile user station 102 named by the PID. When the mobile user station 102 responds to the Specific Poll, the base station 104 should send an Altering N-Note back to the network 126.

0573Table 3-24 Page Response [BS => BSC]

0574Information Element Length in Octets

0575Protocol 1

0576System Type 1

0577Message Type 1

PID 9

CI 1

TCID 1

0581Cipher Key 1 Sequence #

0582Class 2

0583The Page Response N-Note is sent from the base station 104 to the network 126 as soon as a specific poll response, which is the result of an Setup N-Note initiated specific poll, is received from the mobile user station 102 named by the PID. This notification can be used by the network 126 to indicate a successful attempt to find a specific mobile user station 102. If the network 126 does not receive Page

0584Response from the base station 104 sometime after the network 126 has sent a Setup N-Note to the base station 104, the network 126 may infer that the given mobile user station 102 is not currently reachable through this base station 104. Being unavailable should trigger a Deregistration sequence. Table 3-25 Register [BS &lt;= BSC]

0585Information Element Length in Octets

0586Protocol 1

0587System Type 1

0588Message Type 1

PID 9

0590Registration Type 1

0591Registration Info 18

0592Cipher Key Sequence 1 #

0593Class 2

0594The Register N-Note is sent to the network 126 from the base station 104 as a result of the completion of an acquire and registration poll and control traffic sequence between the mobile user station 102 and the base station 104. This message requests that resources needed to access application end user be allocated in the network 126 for this mobile user station 102. If these resources have already been allocated, then the network 126 should not allocate new resources. In any event, the network 126 should reply with a Registration Result N-Note.

0595Table 3-26 Registration Result [BS &lt;= BSC]

0596Information Element Length in Octets

0597Protocol 1

0598System Type 1

0599Message Type 1

PID 9

CI 1

0602Follow On Proceed X

0603Registration Result 1 Code

0604Cause 1 The Registration Result N-Note is sent to the base station 104 from the network 126 when the higher order network infrastructure responds to the mobile user station's Register request .

0605Table 3-27 Release Link [BS &lt;= BSC]

0606Information Element Length in Octets

0607Protocol 1

0608System Type 1

0609Message Type 1

PID 9

CI 1

TCID 1

0613Causes 1

0614The N-Note Release Link is sent by either the base station 104 or the network 126 to indicate that the sender wishes to release the link. If the TCID is non-zero, the Release Link is for a virtual circuit and the request is ignored. If the TCID is zero, a Release Link Complete message is always sent (even if recipient does not recognize the PID) .

0615Table 3-28 Release Link Complete [BS &lt;= BSC]

0616Information Element Length in Octets

0617Protocol 1

0618System Type 1

0619Message Type 1

PID 9

CI 1

TCID 1

0623The Release Link Complete N-Note is sent by either the base station 104 or the network 126 to indicate that the sender has released the channel and the TCID. Table 3-29 Service Information [BS &lt;= BSC]

0624<img file="WO9713353A1_D0006.tif" />

0625The Service Information N-Note is sent from the base station 104 to the network 126. This message informs the network 126 of the bearer channels that have been assigned by the base station 104 for this call.

0626Table 3-30 Cipher Mode [BS &lt;= BSC]

0627Information Element Length in Octets

0628Protocol 1

0629System Type 1

0630Message Type 1

PID 9

CI 1

0633Cipher Algorithm ID 1

0634Cipher Key 8

0635Request PID Type 1

0636The Set Cipher Mode N-Note is sent from the network 126 to the base station 104. It requests the base station 104 to set the mode key and key sequence of its encryption equipment. The base station 104 does not enable its encryption equipment at this time.

0637Table 3-31 Service Request [BS => BSC]

0638Information Element Length in Octets

0639Protocol 1

0640System Type 1

0641Message Type 1

PID 9

CI 1

TCID 1

0645Resource Request 2 Data

0646Network Service 16 Request Data

0647The Service Request N-Note is sent to the network 126 the base station 104 upon the completion of CT-SRQ control traffic exchange. Failure to respond will result in dropping the connection between the base station 104 and mobile user station 102.

0648Table 3-32 Service Response [BS &lt;= BSC]

0649Information Element Length in Octets

0650Protocol 1

0651System Type 1

0652Message Type 1

PID 9

CI 1

TCID 1

0656Network Service 3 Response

0657Cause 1

0658The Service Response N-Note is sent to the base station 104 by the network 126 to notify the base station 104 of the results of the base station's Service Request message.

0659Table 3 -33 Set Link [BS &lt;= BSC]

0660Information Element Length in Octets

0661Protocol 1

0662System Type 1

0663Message Type 1

PID 9

CI 1

TCID 1

0667Resource Request 2 Data

0668Connection 3 Number

0669Transport Method 4 The Set Link N-Note is sent to the base station 104 from the network 126 to notify the base station 104 of a SETUP message from the network 126.

0670Table 3-34 Terminating Handover [BS => BSC]

0671Information Element Length in Octets

0672Protocol 1

0673System Type 1

0674Message Type 1

PID 9

CI 1

0677(Old) Zone 5

0678(Old) BSC ID 2

0679Connection 3 Number

0680(New) Backhaul 1 Map Type

0681(New) Backhaul 4 Map

0682The Terminating Handover N-Note is sent from the base station 104 to the network 126 after an mobile user station 102 has acquired a base station channel (i.e., time slot) on the terminating base station 104 and has completed the Terminating Handover Request Control Traffic sequence. This message contains the PID and Universal Phone number of the mobile user station 102, as well as the Connection Number, Zone and base station controller ID of the base station controller which had been previously carrying the connection. This information is used by the network 126 to establish a bearer connection to the previous connection and to inform the old base station 104 to release its connection and the resources allocated to this mobile user station 102. Within a reasonable amount of time, the network 126 should respond to the base station 104 with a Circuit Switch Complete N-Note signifying that this base station 104 is now connected to the proper bearer channel. Table 3-35 Terminating Handover Complete [BS => BSC]

0683Information Element Length in Octets

0684Protocol 1

0685System Type 1

0686Message Type 1

PID 9

0688The Terminating Handover Complete N-Note is issued from the terminating base station 104 to the terminating application end user connected to the base station controller 105 when a mobile user station 102 has completed its transfer of its bearer traffic from the originating base station 104 to the terminating base station 104. This happens when the mobile user station 102 issues a Terminating Handover Complete O-Note to the terminating base station 104.

0689Table 3-36 Transfer Complete [BS => BSC]

0690Information Element Length in Octets

0691Protocol 1

0692System Type 1

0693Message Type 1

PID 9

CI 1

0696The Transfer Complete N-Note is issued from the base station 104 to the network 126 when a mobile user station 102 transfers its bearer traffic from the originating base station 104 to the terminating base station 104. This is assumed to occur when the originating base station 104 sends a Circuit Switch Complete (CSC) O-Note to the mobile user station 102. Table 3-37 Transport [BS <=> BSC]

0697Information Element Length in Octets

0698Protocol 1

0699System Type 1

0700Message Type 1

PID 9

CI 1

TCID 1

0704Channel 1 Preference

0705TC Data Length 2

0706TC Data <variable>

0707The Transport N-Note is sent from the base station 104 to the network 126 to send signaling or bearer data to the network 126.

0708Table 3-38 Transport Delivered [BS &lt;== BSC]

0709The Transport Delivered Note is sent from the BS to the Network Application to signal the Network Application that all segments of the Transport Note have been delivered send signaling data to the Network Application. The Transport Delivered Note is triggered by an ACK

0710(successful ARQ) of the final segment (CT-TRA) of the Transport Note over the O-Interface. It does not imply delivery of the Transport Note to the ultimate receiver, it simply confirms that the entire Transport Note has been delivered over the 0- Interface.

0711The Transport Delivered Note provides the BSC with confirmation that the Transport Note has actually been delivered over the radio link. If it doesn't receive this confirmation (e.g., because of the handover) it will re-send the message. This mitigates the problem of only getting part of a Transport

0712Note over the air before a handover occurs. Note that while the BSC can not send another Transport Note for a given TCID during the interval while it is waiting for the Transport Delivered on the last Transport Note to that TCID, it may send another N Notes or a Transport Note to a different TCID.

0713Information Element Length in Octets

0714Protocol 1

0715System Type 1

0716Message Type 1

PID 9

CI 1

TCID 1

0720Cause 1

0721Table 3-39 Update ID [BS &lt;= BSC]

0722Information Element Length in Octets

0723Protocol 1

0724System Type 1

0725Message Type 1

PID 9

CI 1

0728(New) PID 9

0729Zone 5

0730The Update ID N-Note is sent to the base station 104 from the application end user connected to the base station controller 105 to notify the base station 104 to update the identity of the mobile user station 102 described by the PID information element. The New PID information element may represent a temporary identification for the mobile user station 102 as provided for in the definition of the New PID.

0731The mobile communication system 101 transfers information in the form of signaling data within the base station 104 between the base station transceiver 604 and the base station line card processor 606 across the I-Interface 615 in the form of I-Notes. Figure 8 is a diagram of the Fig. 6 system architecture focusing on the base station interfaces, showing the separation between the base station transceiver 604 and the line card processor 606. The base station transceiver 604 and the line card processor 606 preferably each has its own local microprocessor or controller, and its own resident software. Figure 9 is a diagram illustrating a breakdown of software functionality for operations, administration, maintenance and provisioning (OAM&amp;P) within a base station 104. In Fig. 9 is shown a functional division between base station transceiver software 909 and the line card processor software 908. The base station transceiver software 909 and line card processor software 908 are directed to the control of managed objects. The line card processor software 908 is responsible by itself for the control of a base station manager managed object 920, and shares responsibility with the base station transceiver software 909 for control of a base station managed object 921, transceiver managed objects 922, and channel managed objects 923.

0732The base station manager managed object 920 is responsible for communication of high layer information between the base station 104 and the base station controller 105, and for the management of all functionality related to the line-card processor 606. The base station managed object 921 provides the OAM&amp;P control functions common to one or more transceivers, and is responsible for all OAM&amp;P base station functionality other than the line card processor 606. The transceiver managed objects 922 are responsible for the management of the base station equipment that provides the time slot structure shown in Fig. 3, including modulation and transmission of information data as well as reception and demodulation. The channel managed objects 923 are responsible for the management of individual physical channels (i.e., separate time slots 302) .

0733Control of the OAM&amp;P functions are carried out across the OOMT interface between the base station controller 105 and the base station 104 shown in Fig. 6. In a preferred embodiment, the I-Interface 615 includes a dual port random access memory (RAM) . Figure 14 is a high-level diagram of a base station 104 including a dual-port RAM 1401 for implementing the I-interface 615. Application information 1407, 1408 is communicated across the I-interface using the dual-port RAM 1401. The base station transceiver 604 and line card processor 606 each comprise an I-interface manager 1405 and 1404, which may be implemented as software subroutines. The I-interface managers 1404, 1405 facilitate transfer of information across the I-interface 615.

0734The physical interface to the dual-port RAM 1401 is preferably identical for both the base station transceiver 604 and the line card processor 606. The base station transceiver 604 comprises boot code 1409 (in addition to operational code) ; thus, two modes of use are provided: (1) a non-operational mode, wherein the dual-port RAM 1401 may be used for initialization of the base station transceiver 604 (including software download from a base station controller 105, if desired) , and (2) an operational mode, wherein the dual-port RAM 1401 is used for transfer of information to and from an application end user 602 using the I-interface 615.

0735The dual port RAM 1401 comprises a common memory which may be accessed by both the line card processor 606 and the base station transceiver 604 in the base station 104. The line card processor 606 and the base station transceiver 604 transfer information across the I-Interface 615 by reading and writing I- Notes to the common dual port RAM 1401. The dual port RAM 1401 is also used for transfer of bearer information for each of the time slot channels, and thus comprises adequate storage to transfer data blocks to and from mobile user stations 102.

0736Alternatively, the bearer data could be provided in a direct link to the line card processor 606 from the base station transceiver 604.

0737System requirements may specify that certain events or messages have a greater priority over other events occurring in the system. For example, handoff events or emergency events may have a relatively high priority. Call control events may also have a relatively high priority, but less than that of handoff events or emergency events. Application messages may be given a lower priority than signaling messages.

0738The I-interface may be configured so as to facilitate prioritization of various events and system messages. A plurality of distinct priority groups may be defined. In a particular embodiment, three priority groups are defined, a high priority group including, e.g., handoff events and emergency events, a medium priority group including, e.g., communication management events and call control messages, and a low priority group including other types of less urgent messages. A plurality of prioritized queues may be provided, each prioritized queue associated with one of the three priority groups. Each prioritized queue comprises a plurality of message buffers (preferably fixed length message buffers) . Messages from the high priority group are placed in a first queue; messages from the medium priority group are placed in a second queue; and messages from the low priority group are placed in a third queue. The I-interface managers 1404, 1405 keep track of the prioritized queues and handle message transfers to and from the queues. The queues may each operate on a "first-in first-out"

0739(FIFO) basis. Where several messages are to be aggregated for delivery or reception over a particular channel (e.g., time slot) , each channel may be provided with its own individual FIFO. Both "send" and "receive" queues are provided for bi- directional transfer of information.

0740The I-interface managers 1404, 1405 each implement at least three software functions with respect to the prioritized queues. A first software function returns a pointer to the next available send NOTE buffer in the designated queue. A NULL return pointer indicates that the queue is full. A second software function activates any semaphore and updates pointers for a queue acting on the current send NOTE buffer. A zero return value indicates success. A third software function returns a pointer to the next available NOTE buffer in the designated queue. A NULL return pointer indicates that the queue is full.

0741Figure 15 is a table of an exemplary partial map for a dual-port RAM 1401. The dual port RAM map includes the total number of prioritized queues and, for each queue, the address of a read ("get") pointer, the address of a write ("put") pointer, the start address of the queue, and the queue length.

0742The dual-port RAM 1401 is used for both bearer data message transfer and prioritization of certain signaling messages. Bearer data messages are stored in predefined locations in the dual-port RAM 1401, and can be accessed by either the line card processor 606 or the base station transceiver 604. The dual-port RAM 1401 may preferably hold at least 2,304 bearer-bytes of information (for a base station 104 supporting up to 32 user stations 102) , and has an additional 32 kilobytes for the prioritized queues.

0743Figure 16A is a block diagram of a base station 1601 in accordance with one embodiment of the present invention. In Fig. 16, a dual-port RAM 1609 (e.g. , dual-port RAM 1401 of Fig. 14) comprises a plurality of queues 1615, 1616, and 1617, and buffers 1620, 1621 for storing messages originating from and destined for user stations 102. An over-the-air (OTA) interface 1607, under control of an OTA controller 1606, transmits and receives messages from user stations 102. A line card interface 1611, under control of a line card controller 1610, transmits and receives messages from a base station controller 105 (see Fig. IB) . A base station global bus controller 1605 controls mode selection of the OTA controller 1606 and line card controller 1610, handles interrupts, and responds to commands from the system regarding operation of the base station 1601 as a whole (e.g. , whether the base station 104 should be on-line or off-line, etc . ) .

0744Figure 16B is a more detailed diagram of internal components of the base station 1601, showing the internal components and connections of the components shown in Fig. 16A. The Fig. 16B diagram shows a global bus 1630 connected to several of the internal components, as well as backhaul lines 1650 from the line card interface 1611 which ultimately connect to the base station controller 105. Figure 17A is a diagram of an exemplary memory map for the dual-port RAM 1401, not considering the map portion for the prioritized queues shown in Fig. 15. Figure 17B is an alternative memory map for the dual-port RAM 1401, and is configured for analog backhaul lines from the base station 104 to the base station controller 105.

0745In a preferred embodiment, the communication system 101 uses I-Notes having the same format as the N-Notes as shown in Fig. 11. Examples of I-Notes which may be communicated across the I-Interface are given in Table 3-1 through Table 3-39. Because messages to and from the user stations 102 are generally not in the form of I-Notes, the base station transceiver 604 translates relevant portions of the over-the-air messages into an I-Note format, and either uses or sends I-Notes received from the line card processor 606 across the I-interface 605. If an O-Note is contained in a B-field 529 of a user message (as indicated by a flag in the header 523) , then the base station transceiver 604 extracts the O-Note and places it in one of the three queues 1615, 1616 or 1617. If an O-Note is contained in segments within D-fields 527 sent over several messages, then the base station transceiver 604 may store the O- Note in a buffer associated with the user station 102 on the particular channel until the entire O-Note is received, and then place the entire O-Note in the appropriate one of the three queues 1615, 1616 or 1617. In some cases, the base station transceiver 604 performs a translation (or removes or adds fields or other information) before storing the message (now an I-Note) in the appropriate queue 1615, 1616 or 1617. Similarly, when the base station transceiver 604 reads an I-Note from the dual-port RAM 1609, it may perform a translation of the I-Note (or remove or add fields as necessary) and insert the message (now an O-Note) in the B-field 559 of a base message, and indicate the presence of an O-Note by setting the appropriate flag in the base message header 553. If the O- Note does not represent a relatively urgent signaling message, and voice data or other user data is being sent in the B-field 559, the base station transceiver 604 may send the O-Note in segments over a plurality of base messages, utilizing the D- field 557.

0746In a preferred embodiment, the communication system 101 operates with Notes which contain common Information Elements which may be passed across several system interfaces. Table 4-1 through Table 4-65 describe Information Elements which may be included in Notes which are communicated across system interfaces in a preferred embodiment of the communication system 101. Information Elements may comprise signaling data which is used by components within the communication system 101 to perform functions in support of one or more application end users. A specific Information Element, referred to as Transport Data, comprises application level data and is described in Table 4-62.

0747Table 4-1 ACK'ed Command [0,M]

0748The ACK'ed Command information element contains the Type of the specific command being acknowledged. The values are the same as the Message Type on the given interface.

0749Bits Octets 4 3

0750ACK'ed Command

0751Table 4-2 ACK Response [0,M]

0752The ACK Response information element contains the acknowledgment response.

0753Bits Octets

07546 5 4 3 2 1

0755ACK'ed Response

0756ACK Response

07570 Successful acknowledge

07581 Unsuccessful acknowledge (NAK)

07592-255 Reserved

0760Table 4-3 Assist Data [O, M, N, I]

0761The Assist Data element is a 144 bit field that is used by the sender to pass information to the receiver. This information may or may not have been solicited by an Assist Request. The format and meaning of the Assist Information is dependent upon the Assist Type. Bits Octets 6 5

0762144 bit Assist Data 1 2 3 4

076318

0764Table 4-4

0765Assist Request Info

0766The Assist Request Info element is a 144 bit field that is used by the sender of an Assist Request to provide additional information identifying the request. The most likely use of this element will be to provide a PID when requesting information about a specific user station 102. This information element also contains the identity of the requester so that the requester can be named as the recipient of the Assist Information message which results from this request. The format and meaning of the Assist Request Info is dependent upon the Assist Type.

0767Bits Octets 4 3

0768Assist Requester 141 bits Assist Request Info 1 2 3 4 Same values and meanings as the Assist Msg Recipient subfield of the Assist Type information element.

0769Table 4-5

0770Assist Type [O, M, N, I]

0771The Assist Type is divided into two subfields,

0772Bits Octets

07738 6 5

0774Assist Msg Assist Item Recipient

0775Table 4-5.1

0776Assist Item

0777Identifies the Information being Requested.

0778<img file="WO9713353A1_D0007.tif" /> Table 4 -5 .2

0779Assist Msg Recipient

0780Identifies the recipient of the assist message. If the message is an Assist Request message, then the recipient is the Information Source (i.e., the process which provides the information) . If the message is an Assist Information message, then the recipient is the Information Destination (i.e., the process which may use the information) . If the Assist

0781Information message was requested, the Assist Message Recipient will be the Assist Requester subfield of the Assist Request Info information element of the Assist Request message is unsolicited, the sender will be able to supply the Assist Message Recipient independently.

0782The following recipients are defined:

0 MS-APP

1 MS-OTA

2 BS-OTA

07863 BS-Line Card

4 BSC

07885-7 Reserved

0789Table 4-6

0790Authentication Test Number [O, M, N, I]

0791The Authentication Test Number information element contains a 16 byte (128 bit) value to be used in authenticating an user station 102. Table 4 - 6 . 1

0792Key Type is DCS1900:

0793If the Protocol of an Authenticate message is DCS1900, then the authentication parameter is a 128 bit pseudo random number which is sent to the user station 102 for the authentication process.

0794Bits Octets

0795128 bit Pseudo Random Number 1

07962

07973

07984

07995

08006

08017

08028

08039

080410 11 12 13 14 15 16

0805Table 4-6.2

0806Protocol is Bellcore "C"

0807If the Protocol is Bellcore "C", then the authentication parameter is RAND (a random number) , 64 bits of which are to be used by the base station 104 in the authentication process. Bits Octets

080864 bit RAND 1

08092

08103

08114

08125

08136

08147

08158

0816Reserved 9

081710 11 12 13 14 15

0818Reserved 16

0819Table 4-7

0820Authentication Test Response [O, M, N, I]

0821The contents of the Authentication Test Response information element depends upon the infrastructure of the system. If the Authenticate N_Notes RMT message^' that stimulated the response was of type DCS1900, then the contents is the 32 bit result of applying the authentication algorithm to the pseudo-random number supplied. If the Authentication N_Notes RMT message was of Bellcore "C" type, then a single bit of the result signifies either successful authentication or failure. Table 4 -7. 1

0822DCS1900 Response

0823Bits Octets 6 5 4 3

0824Response Data 1

0825Response Data 2

0826Response Data 3

0827Response Data 4

0828Reserved 5

0829Reserved 16

0830Table 4-7.2

0831IS-54 Response

0832Bits Octets

08335 4 3

0834Result 1

0835Reserved 2 3 4 5

0836Reserved 16

0837Result

08380 Authentication Success

08391 Authentication Failure

08402-255 Reserved Table 4-8

0841Auth Type [O]

0842The Authentication Type information element defines the type of infrastructure that is providing the authentication procedure.

0843Bits Octets

0844Auth Type

0845Auth Type

08460 DCS1900 Authentication

08471 Bellcore Generic C Authentication

08482-255 Reserved

0849Table 4-9

0850High Bandwidth Bearer data

0851Bits Octets 6 5 4 3 2 1

0852<TBD> bits of bearer data 1 2

0853<TBD> Table 4-9.1

0854Low Bandwidth Bearer Data

0855The Low Bandwidth Bearer Data Element consists of fewer bits of user data than the High Bandwidth Bearer Data Element. Data transmitted via this mode may suffer temporal distortion but will be correctly delivered with no undetected lost or duplicated packets to the limits of the FCW algorithm.

0856Bits Octets 5 4

0857<TBD> bits of bearer data 1 2

0858<TBD>

0859Table 4-9.2

0860Symmetric Bandwidth Bearer Data

0861The Symmetric Bandwidth Bearer Data Element consists of 192 bits of user data. The low order bit of the 192 bit number resides in Bit 1 Octet 1 while the high order bit of the 192 bit number resides in Bit 8 of Octet 24. Data transmitted via this mode may suffer temporal distortion but will be correctly delivered with no undetected lost or duplicated packets to the limits of the FCW algorithm. Bits Octets

0862192 bits of bearer data 1 2

086324

0864Table 4-10

0865Backhaul Map [N, I]

0866The Backhaul Map information element details the allocation of backhaul channels on the backhaul link between the base station 104 and the base station controller 105. There are two types of Backhaul Maps. The first is the Superframe Backhaul Map, which consists of a bit map showing the specific backhaul channels assigned to the MS represented by the Personal ID associated with the N_Notes RMT message in which the Backhaul Map appears. The second type is the Subframe Backhaul Map, which identifies a single backhaul channel and the submultiplexing rate to be applied to the channel.

0867When the Backhaul Map Type is Superframe :

0868Bits Octets

08698+

087032 bits of backhaul channel absolute position 1 2 3 4 When the Backhaul Map Type is Subframe

0871Bits Octets

08728 7 6 5 4 3

08738 bits Backhaul channel # 1

0874Multiplex rate 2

0875Multiplex rate offset 3

0876Reserved 4

0877Reserved (transmitted) bits are always set to zero and received reserved bits are also ignored.

0878The multiplex rate defines the number of channels to be allocated. Multiplex Rates Offset specifies the relative frame position to the next channel to be used. One indicates transmission in the next channel .

0879Table 4-11

0880Backhaul Map Type [N, I]

0881The Map Type information element is used to define the type of Backhaul Map that follows. There are two types of Backhaul Maps: Superframe and Subframe. Superframe maps detail the assignment of one or more complete 9.6 kbps backhaul channels in the base station 104 to base station controller 105 backhaul link to a single call. Subframe maps describe the submultiplexing characteristics of a less than 9.6 kbps rate onto a single 9.6 kbps backhaul channel.

0882Bits Octets

08838 bit Map Type

0884Map Type

08850 No Map

08861 Superframe

08872 Subframe

08883-255 Reserved If Backhaul Map Type indicates No Map, then the Backhaul Map should be zero.

0889Table 4-12

0890Base ID [O, M, N, I]

0891The Base Identifier, in conjunction with the PLMN, uniquely identifies the specific base station 104. The low order bit of the 32 bit number is located in Bit 1 Octet 1. The high order bit of the 32 bit number is located in Bit 8 of Octet 4.

0892Bits Octets

08938 7 6 5 4 3 2 1

089432 bits of unique Base Identification 1

0895(2 octets) 2

0896Cell Size ID 3

0897Cell Size ID/Pole Position/TRX Unit 4

0898Table 4-13

0899Base Status [N, I]

0900The Base Status information element is comprised of 32 octets.

0901Bits Octets

090232 Octets of Base Status 1 2

090332 Table 4-14 Base ID: Cell Site ID

0904The Cell Site ID Field consists of 10 bits which are used o identify a particular physical cell site within the Zone, (e.g., a particular "light pole".)

0905<img file="WO9713353A1_D0008.tif" />

0906Base ID: Pole Position

0907The Pole Position Field consists of 4 bits which are used to identify a particular Base Station with the Cell. It is used to distinguish between different Base Stations at the same Cell Site (e.g., "on the pole") .

0908<img file="WO9713353A1_D0009.tif" />

0909Base ID: TRX Unit

0910The TRX Unit Field consists of 2 bits which are used to identify a particular TRX Unit within the Base Station.

0911Meaning

0912Value

09130 Reserved (for 'Either TRX Unit')

09141 TRX Unit 1

09151 TRX Unit 2

09163 Reserved (for 'both TRX Units') or DCS 1900, only values 2 and 2 are meaningful Values 0 and are unused.

0917Table 4-15 Base Status [N, I]

0918The Base Status information element shall be comprised of 32 octets.

091918 Octets

092032 octets of Base Status 1 2

092132

0922Table 4-16

0923Broadcast ID [O]

0924The Broadcast ID information element is used to identify specific broadcast data streams. The ID is assigned to the specific broadcast stream on a connection basis. It is the responsibility of the broadcast Network Application to provide periodic application broadcast heading information. The Broadcast ID is assigned at the start of a connection and released to the Broadcast ID pool at the termination of the connection.

09258 7 6 5 4 3 2 1 Octet s

09268 bits of Broadcast ID Table 4 - 17

0927BS Capabilities [0, M]

0928The BS Capabilities information element describes the services being offered by the BS. The internal format of this element is shown below.

0929Octets

0930Base Features 1

0931Base Features 2

0932Base Features Access Class 3

0933Leveling Bits 4

0934IBS Capabilities: Base Features

0935The Base Features subfield is 20 bits in length. These bits are used to provide the MS information about the base and correspond to various base capabilities or features. Features such as ethernet access, aggregate data capability, enhanced voice, etc. are selected here. The particular features depend upon the networks which the BS supports.

0936BS Capabilities: Base Features for DCS1900 Systems

09378 7 6 5 4 3 2 1 Octets

0938Base Features 1

0939Base Features 2

0940Base Features .„-__. 3

09411 Bit: This bit, if set to 1, indicates that the BSC which services this BS is capable of Inter-BSC Terminating Handovers.

09421 Bit: More Slots (OTA) than Channels (Backhaul; All bits not explicitly defined are reserved. BS Capabilities: Access Class

0943Integral value from 0 through 15 which designates the lowest class allowed access to the base. That is, if the MS were provisioned with an access class of 3 , it would be allowed to register with base stations that broadcast an access class of 3 or lower. This subfield is active only if the CU field in the Header specifies that Class Control is in effect.

0944Value Access Allowed to

094515 Test Mobiles only

094614 911 calls only

094713 Reserved

094812 Reserved

094911 Reserved

095010 Mobiles with Access Class 10

09519 Mobiles with Access Class 9 or 10

09521 Mobiles with Access Class 1, 2, ... 10

09530 All Mobiles

0954BS Capabilities: Leveling Bits

09558 bits, set by the base station to level out the number of mobile stations registering or using a base. A mobile station would be allowed to access a base station if the leveling bit of the mobile station was set in this field. The leveling bit number will be selected by taking the modulo 8 of the MS's Permanent PID. If the corresponding bit in the base station leveling field were set then the MS would be allowed access, otherwise, the MS would have to access another BS. This subfield is active only if the CU field in the Header specifies that Class Control is in effect. Table 4 -18

0956BS Information [M]

0957The BS Information Element is a collection of Information Elements which give details associated with a BS. It exists for notational convenience because of its frequent occurrence in lists .

0958Bits Octets

0959Zone [5 Octets] 1

09602

09613

09624

09635

0964BSC ID [2 Octets] 6

09657

0966Base ID [4 Octets] 8

09679

096810

096911

0970BS Capabilities [4 Octets] 12

097113

097214

097315

0974Table 4-19

0975BSC ID [O, M]

0976The base station controller identifier, in conjunction with the PLMN, uniquely identifies the specific base station controller 105. The low order bit of the 16 bit number is located in Bit 1 Octet. The high order bit of the 16 bit number is located in Bit 8 of Octet 2. Bits Octets

09778 7 6 5 4 3 2 1

097816 bits of unique BSC identification 1 2

0979Table 4-20

0980Cause [O, M, N, I]

0981The Cause information element consists of 8 bits identifying the cause for, or the result of, a specific action. The particular meanings of Cause values are determined by the message in which the Cause information element appears.

0982Bits Octets 5

09838 bits of Cause information

0984Table 4-21.1

0985Cause: Authentication Reject [N, J] CT-RCP [0]

0986Registration Result [M, N, J] Service Response [M, N, I]

0987Value Meaning

09880 Success

09891 IMSI Unknown in HLR

09902 Illegal MS

09913 Illegal ME

09924 PLMN Not Allowed (i.e., don't try any cells with same MCC, MNC)

09935 LAI Not Allowed (i.e., don't try any cells with the same LAI)

09946 National Roaming Not Allowed in the

LAI

09967 Protocol Error

09978 Network Failure

09989-255 Reserved Table 4 - 21 . 2

0999Cause: Cipher Response [N, I]

1000Value Meaning

10010 No Result

10021 Success, Cipher

10032 Success, Clear Mask

10043 BS Reject

10054 MS Reject

10065-255 Reserved

1007Table 4-21.3 Cause: Connect Link [N, I] Setup Link [N, I]

1008Value Meaning

10090 Link Successful

10101 Link Failure

10112-255 Reserved

1012Table 4-21.4 Cause: CT-ACK [O]

1013Unless specified otherwise below, the Cause Information Element in CT-ACK messages always has a value of zero.

1014Table 4-21.4.1

1015Cause: CT-ACK in response to CT-CSC

1016Value Meaning

10170 Acknowledged

10181 Circuit Switch Refused

10192-255 Reserved Table 4-21.5 Cause: CT-CIP [O]

1020Value Meaning

10210 Set or Change Cipher

1022Synchronize Cipher

10232-255 Reserved

1024Table 4-21.6 Cause: CT-CNC [O]

1025Value Meaning

10260 The requested connection has been connected

10271 Unable to complete the requested connection

10282-255 Reserved

1029Table 4-21.7 Cause: CT-DRG [O] Deregister [M, N, I]

1030Value Meaning

10310 Release by MS

10321-255 Reserved

1033Table 4-21.8 Cause: CT-HOF [O] Handover Failed [N, I]

1034Value Meaning

10350 Reserved

10361 Refused by Originating BS

10372 Refused by Terminating BS

10383 Refused by Originating BSC

10394 Refused by Terminating BSC

10405 THR Failed, OHR Suggested

10416 Invalid HRef

10427-255 Reserved Table 4-21.9 Cause: CT-REL [O]

1043Release Link [M, N, Il

1044Value Meaning

10450 Release by Network

10461 Release by MS

10472 Release by BS (Link Lost)

10483 Release by BS During Handover (e.g., Circuit Switch Complete)

10494-255 Reserved

1050Table 4-21.10 Cause: CT-SET [O]

1051Value Meaning

10520 Link Successful

10531 Link Failed

10542-255 Reserved

1055See Cause: CT-DRG [O] See Cause: CT-HOF [0]

1056Table 4-21.11 Cause: Handover Request ACK [N, I]

1057Value Meaning

10580 No Result

10591 Success, Cipher

10602 Success, Clear Mask

10613 Fail, No Resources

10624 Fail, Cipher Algorithm Not Supported

10635-255 Reserved

1064See Cause : CT-RCP [0] See Cause : CT-REL [O]

1065Table 4-21. 12 Cause : Service Info [O]

1066This Cause is unique in that it is divided into two subfield to carry results for both the MS and the BS. Bits Octets

1067MS Cause BS Cause

1068The meanings of each subfield are:

1069Value Meaning

10700 Success

10711 Failure

10722-15 Reserved

1073See Cause: CT-RCP [O]

1074See Cause: Connect Link [N, I]

1075Table 4-21.13 Cause: Specific Poll Result [O]

1076<img file="WO9713353A1_D0010.tif" />

1077Cause: DCS1900 Systems

1078For DCS1900, the mapping of GSM Causes to Omnipoint Causes is given in the following tables. This translation is for CT- RCP, CT-SRS, Register_Cnf, Registration Result, Service Response.

1079Omnipoint GSM Meaning Value Value

10800 0 Success

10812 2 IMSI unknown in HLR

10822 3 8/27/1996 Illegal MS

10832 4 IMSI unknown in VLR

10845 IMEI not accepted 2 6 Illegal ME

10853 11 PLMN not allowed

10864 LAI not allowed

10874 13 National Roaming not allowed In this LAI

10885 17 Network Failure

10895 22 Congestion

10906 32 Service option not supported

10916 33 Requested service option not subscribed

10926 34 Service option temporarily Dut of order

10936 38 Call cannot be identified

109495 Semantically incorrect tiessage

10956 96 Invalid mandatory information

10966 97 Message type non-existent not implemented

10976 98 Message not compatible with protocol state

10986 99 Information element non- ≥xistent or not implemented

10996 100 Conditional IE error

11006 101 Message not compatible with protocol state

11016 111 Protocol error, unspecified

1102Table 4-22 Channel Preference [M.N.I]

1103The Channel Preference information element indicates the sender's preference for which channel--B or D--is used over the O Interface to transport the data contained in the message. Octets

11048 bit Channel Preference

1105Value Meaning

11060 B Channel Preempt: Use existing circuit; do not attempt to acquire

1107Separate Signaling Slot .

11081 B Channel Required: Importance relatively high: use Separate

1109Signaling Slot if available, otherwise preempt B Channel.

11102 B Channel Preferred: Moderate

1111Importance: use Separate Signaling

1112Slot if available, otherwise use

1113D Channel

11143 D Channel Preferred: Importance relatively low; use D Channel if B

1115Channel is not available.

11164-255 Reserved

1117There is no purpose to having a D Channel Required value -- it would only be useful in the case where the B Channel was available and the application wanted the OTA to use the D Channel anyway. Such a request would be ignored byte OTA to conserve bandwidth (pushing a Transport Note through the D Channel at a rate of one byte per frame while wasting the 19 bytes available in the B channel -- it could take up to 5 seconds to get the Transport Note through this way -- is just too wasteful of resources) .

1118Channel Preference: DCS1900 Systems

1119For DCS1900 Systems, the following mapping will suffice--a more sophisticated mapping would probably select some messages with TCID 0 which could be assigned a preference of D Channel Preferred. E.g., Start/Stop DTMF, Advice of Charge, etc. : TCID Channel Comments Preference

11200 1 B Channel required for CC, MM and SS Transport

11213 3 D Channel preferred for SMS Transport

1122Table 4-23 Channel Rate

1123The Channel Rate information element appears both as a 4- bit field in the Resource Request Data information element and as a 1-octet information element in other messages. Only values 0-15 are legal, all higher values are illegal since they will not fit in 4 bits. Only values 0-6 have been defined; the remaining 8 values will be defined when needed from the remaining 14 candidate Channel Rates.

11248 Octets

1125Reserved 4 bit Channel Rate

1126Value Channel Rate Equivalent Raw in Slots/Frame Data Rate (bits/second)

11270 1/32 300

11281 1/16 600

11292 1/8 1,200

11303 1/4 2,400

11314 4, 800

11325 1/1 9,600

11336 2/1 19,200

11347-15 Reserved

1135Candidate 3/1 28, 800

1136Candidate 4/1 38,400

1137Candidate 5/1 48,000

1138Candidate 6/1 57,600 Candidate 7/1 67,200

1139Candidate 8/1 76,800

1140Candidate 9/1 86,400

1141Candidate 10/1 96, 000

1142Candidate 11/1 105,600

1143Candidate 12/1 115.200

1144Candidate 13/1 124,800

1145Candidate 14/1 134,400

1146Candidate 15/1 144,000

1147Candidate 16/1 153,600

1148Candidate Illegal Not Applicable

1149Channel Rate: DCS1900 Systems For DCS1900 Initial Deployment, only value 5 (1 slot/frame) is supported. In the future, when aggregated data is supported, the other values will be supported as well .

1150Table 4-24 Cl (Correlative ID) [0,N,I]

1151The Cl (Correlative ID) is a single octet which serves as a short-hand identifier (nickname) for an active MS. Cis are managed by the BS and are (currently) guaranteed to uniquely identify an active MS during a session. AN MS will be assigned a new (probably different) Cl at the beginning of each session. 8 7 6 5 4 3 2 1 Octets

11528 bits of correlative ID

1153Notes passed over the N and I interfaces generally contain a PID which the BS OTA must use to associate the Note with the particular OTA link. Since the PID is nine bytes in length, this can potentially be a compute intensive process. To simplify the BS's task of mapping a Note to a particular slot, the Cl shall be included in each RMT Note which contains a PID in both directions over the O and I interfaces. Notes which do not contain a PID do not include a Cl . 91

1154The Cl occupies the D Channel on all 0_Notes except CT-GPO (General Poll) and possibly CT-GPR (General Poll Response) . It is used by the MS to identify 0_Notes meant for it. This allows the MS to recover from an error during Fast Control Traffic. The management of Cis will be according to the following rules:

1155• The BS will assign a unique Cl to each mobile during slot acquisition. The BS will use a FIFO queue to manage Cis to spread Cl usage over the entire legal range and insure a maximal delay between reuse of a given Cl . Legal Cl values are 1 to 255.

1156• The BS will include the Cl in each Notes_RMT message to the BSC (in those messages which contain a PID) .

1157• The BSC will retain the Cl and return it to the BS in all messages containing the same PID (i.e., the PID received with the Cl from the BS) . The BSC must always save and use the most recent value of the Cl received from the BS. In future, there is a possibility that the Cl may change in middle of session (upon entry/exit from Slow Control Traffic) . This will only occur if at some future date there is a requirement to simultaneously support a total of more than 255 active mobiles. In theory it is possible to have 15 slots all fully occupied with mobiles communicating once every 25 frames. This is the worst case and will probably never happen, but is provides a theoretical maximum of 15 * 25 = 375 active Mobiles at any one time. Since this exceeds the 255 maximum Cl limit, we must make provision for separate numbering of mobiles in slow control traffic and would need to deassign/reassign Cis on the entry/exit of Slow Control Traffic mode. The implication that this has on the current design is imply that the Cl may not be guaranteed unique over the entire session for a given mobile. In addition to the requirement (above) that the BSC always save and use the most recent value of the Cl received from the BS, it imposes the following additional limitations on the use of Cis as handles to information concerning the MS:

1158• If the BSC uses the Cl as a handle -- which it may as an implementation option -- it must verify that the

1159^' PID in the data record found matches the PID which accompanied the Cl in the Note. If the two PIDs do not match, the BSC must ignore the Cl and use the PID in the note to identify the appropriate data record. This insulates the BSC programming from having to change if Cis ever cease to be unique. If the BS ever manages Cis in a fashion that does not guarantee their uniqueness, the BS also must verify that the PID in the date record found matches the PID which accompanied the Cl in the Note. if the two PIDs do not match, the BS must ignore the Cl and use the PID in the Note to identify the appropriate data record.

1160The MS must also use the most recent Cl it receives from the BS in a Specific Poll--CT-SPO--which contains its PID.

1161Table 4-25 Cipher Algorithm ID [N, I]

1162The Cipher Algorithm ID specifies that algorithm to be used for ciphering.

1163Bits Octets

11648 7 6 5 4 3 2 1

11658 bits &lt; Df Algorithm ID 1

1166Algorithm ID

11670 Transparent (Clear)

11681 A5/1 Algorithm

11692 A5/2 Algorithm

11703 A5/3 Algorithm

11714-255 Reserved

1172Table 4-26 Cipher Key [N, I]

1173The Cipher Key information element contains the clear text key to be used to set the key of the BS's encryption equipment. Bits Octets

11748 7 6 5 4 3 2 1

117564 bit Clear Text Cipher Key 1 2

1176•

1177Table 4-27 Cipher Key Sequence # [O, M, N, I]

1178The Key Sequence # information element is used to select a cipher key in both the BS and MS without having to explicitly pass the key over the air. The Key Sequence # will be generated as defined in <TBD> . Not all bits of the key sequence # may be significant.

1179Bits Octets 6 5 4

11808 bit Key Sequence #

1181Bits 5-8: Must be zero

1182Bits 1-4: Are Significant

1183Default is 'OFx' in there is no Cipher Key Sequence #.

1184Table 4-28 Class [O, N, I]

1185The Class information element specifies some of the operational parameters of the particular typ of MS being used.

1186Bits Octets

11878 7 6 5 4 3 2 1

1188Class Type Class Information 1

1189Class Information 2 Class Type

11900 Reserved

11911 DCS1900 Class Type

11922 IS-41 Class Type

11933-7 Reserved

1194Table 4-28.1 Class Information for DCS1900 Class Type

1195Bits Octets

11968 7 6 5 4 3 2 1

1197Not Available Rese Revision A5/1 A5/2 rved Level

1198A5/3 SM SS Screen Reserved Ind.

1199Revision Level

12000 PCS2000 phase 1 Mobiles

12011-3 Reserved

A5/1

12030 A5/1 encryption algorithm not available

12041 A5/1 encryption algorithm is available

1205<img file="WO9713353A1_D0011.tif" />

SM

12070 short message capability not present

12081 short message capability present SS Screen Indicator

12090 GSM phase 1

12101 capable of handling ellipsis notation and phase 2 error handling

12112-3 reserved

1212Table 4-28.2 Class Information for IS-41 Class Type

1213Bits Octets

12148 7 6 5 4 3 2 1

1215Not Available Reserved 1

H G F E D C B A 2

1217Power Class (PCP) (octet 1, bits A, B and E)

1218Bits H G F E D C B A Value Meaning

12190 0 0 - Class I

12200 0 1 - Class II

12210 1 0 - Class III

12220 1 1 - Class IV

12231 0 0 - Class V

12241 0 1 - Class VI

12251 1 0 - Class VII

12261 1 1 - Class VIII

1227Transmission (TX) (octet 1 , bit C)

1228Bits H G F E D C B A Value Meaning

12290 - Continuous

12301 - Discontinuous

1231Bandwidth (BW) (octet 1, bit D)

1232Bits H G F E D c B A Value Meaning

0 - 20 MHZ

12341 - 25 MHZ Table 4-28.2.1 Mobile Station Nominal Power Levels

1235Mobile Mobile

1236Station Attenuation Nominal ERP (dBW) for

1237Power Level Code Mobile Station Power

1238Class

(PL) (MAC) I I I I V V V V I I V I I I I I I I

12400 0000 6 2 * * * ★

12412 2

12421 0001 2 2 * * * *

12432 2

12442 0010 * * * *

12452 2 2 2

12463 0011 * * * *

12476 6 6 6

12484 0100 ★ * * *

12491 1 1 1 0 0 0 0

12505 0101 ★ * * *

12511 1 1 1 4 4 4 4

12526 0110 * * * *

12531 1 1 1 8 8 8 8

12547 0111 * * * *

12552 2 2 2 2 2 2 2

1256Dual Mode Only 8 1000 * * * *

12572 2 2 2 2 2 2 6

1258+ /

12593 d B

12609 1001 * * * *

12612 2 2 3 2 2 2 0

1262+ /

12636 d B

126410 1010 * ★ * *

12652 2 2 3

12662 2 2 4

1267+ /

12689 d B

1269The three lease significant bits of MAC are used in the CMAC/VMAC field. All four bits of MAC are used in the DMAC field.

1270Table 4-29 Connection Number [O, M, N, I]

1271The Connection Number information element specifies the specific network connection which was allocated to carrying the bearer channel of this user station 102 from the base station 104 to the network. All octets of this information element may not be significant. Unused nibbles and octets must be filled with "F" hex.

1272The Connection Number in conjunction with the Zone and the base station controller ID uniquely identify every possible connection in the world.

1273Bits Octets

12748 7 6 5 4 3 2 1

127524 bis of Connection Number 1 2 3

1276Table 4-30

1277Connection Result [M]

1278D Channel [O]

1279The D Channel information element transmits the out of band application channel in a byte serial manner. It is available for this use only when bearer data is being transmitted (i.e., when the Packet Type field in the 0_Note Header has a value of O (Normal Traffic) . During signaling (all other Packet Types) it is used for the Cl (or other special purposes) . ESN [0,M,N,I] The equipment serial number uniquely identifies the MS.

1280Octets

128164 bits of ESN 1 2

1282FCW [O] The Frame Check Word, which checks the content of a packet information element, shall be a 16 bit sequence. It shall be the ones complement of the sum (modulo 2) of: a) The remainder of x^k (x¹⁵+x¹⁴+x¹³+x¹²-ι-x¹¹+x¹⁰+x⁹-ι-x⁸+x⁷-ι-x⁶-ι-x⁵+x⁴+x³+x²-t-x¹+l) divided (modulo 2) by the generator polynomial x¹⁶+x¹²+x⁵+l, where k is the number of bits in the packet not including the FCW. b) The remainder of the division (modulo 2) by the generator polynomial x^lδ+x¹²+x⁵+l of the product of x¹⁶ by the content of the packet existing from and including the first bit of the packet to but not including the first bit of the FCW.

1283Bits 5 4 Octets

128416 bits of FCW 1 2

1285Table 4-31 Correlative ID [O]

1286The Correlative information element is used to temporarily identify a group of frames as being destined to a specific user station 102. The ID is assigned for the duration of the connection and is released for reuse by another user station 102 at the termination of a connection. The specific value of "OFFx" is reserved for broadcast use. The correlative ID for a specific user station 102 will not be changed during a connection.

1287Bits Octets

12888 bits of correlative ID Table 4-32 Count Base [N, I]

1289The Count Base information element is used to specify the number of sets of base information which follow in the Notes_. RMT Originating Handover message. Each set of base information consists of three information elements: Zone, base station controller (BSC) ID and Base ID.

1290Bits Octets

12918 bits of Count Base

1292Table 4-33 D Channel [O]

1293The D Channel information element transmits the out of band application channel in a byte serial manner. The data is transmitted with the low order bit of the D channel information in Bit 1 of the Octet.

1294Table 4-34 ESN [O, M, N, I]

1295The equipment serial number uniquely identifies the user station 102.

1296Bits Octets

129764 bits of ESN 1 2 Table 4-35 Facility [O, M]

1298The Facility information element describes the services being offered by the base station 104. The internal format of this element is shown below.

1299Bits Octets

1300Base Features 1

1301Base Features 2

1302Base Features Access Class 3

1303Leveling Bits 4

1304The Base Features subfield is 20 bits in length. These bits are used to provide the user station 102 information about the base station 104 and correspond to various base station capabilities or features. Features such as ethernet access, aggregate data capability, enhanced voice, etc. are selected here. The particular features depend upon the networks which the base station 104 supports.

1305Table 4-35.1 Base Features for DCS1900 Systems

1306Bits Octets

13078 7 6 5 4 3 2 1

1308Base Features 1

1309Base Features 2

1310Base Features 3

13111 Bit: This bit, if set to 1, indicates that this base station 104 is capable of Inter-BSC Terminating Handovers All bits not explicitly defined are reserved.

1312Table 4-35.2 Facilities: Access Class

1313Integral value from 0 through 15 which designates the lowest class allowed access to the base station 104. That is, if the user station 1021 were provisioned with an access class of 3, it would be allowed to register with base stations 104 that broadcast an access class of 3 or lower. This subfield is active only if the CU field in the Header specifies that Class Control is in effect.

1314Value Access Allowed to

131515 Test Mobiles only

131614 911 calls only

131713 Reserved

131812 Reserved

131911 Reserved

132010 Mobiles with Access Class 10

13219 Mobiles with Access Class 9 or 10

1322•

1323•

1324•

13251 Mobiles with Access Class 1, 2, ... 10

13260 All Mobiles

13278 bits, set by the base station to level out the number of user stations 102 registering or using a base station 104. A user station 102 would be allowed to access a base station 104 if the leveling bit of the user station 102 was set in this field. The leveling bit number will be selected by taking the modulo 15 of the user station PID. If the corresponding bit in the base station 104 leveling field were set then the user station 102 would be allowed access, otherwise, the user station 102 would have to access another base station 104. This subfield is active only if the CU field in the Header specifies that Class Control is in effect.

1328Table 4-36 FCW [O]

1329The Frame Check Word, which checks the content of a packet information element, is be a 16 bit sequence. It comprises the ones complement of the sum (modulo 2) of: a) The remainder of

1330_XK ₍--± _+x14 _+xl J _txl _+xl l_+xl U _+χy _+xo _+x / _xb _{+x &lt;}._{x tx}3 _{+x +x}l _{+1 )} divided (modulo 2) by the generator polynomial x¹⁶+x¹²+x⁵+l, where k is the number of bits in the packet not including the FCW. b) The remainder of the division (modulo 2) by the generator polynomial x¹⁶+x¹²+x⁵+l of the product of x¹ by the content of the packet existing from and including the first bit of the packet to but not including the first bit of the FCW.

1331Bits Octets

13328 7 6 5 4 3 2 1

133316 bits of FCW 1 2

1334Table 4-37 Frame Number [O]

1335The Frame Number information element is used in ciphering algorithms. Each base station 104 keeps its frame number as a count of the number of frames it has traversed since power up.

1336Bits Octets

13378 7 6 5 4 3 2 1

133822 bits of Frame Number 1 2 3

1339Table 4-38 Follow On Proceed [0,M,N_fI]

1340The Follow On Proceed information element contains a single bit of information: either another Network Level Service Request is allowed or it is not.

1341This information element also appears as a 1 bit field in the Registration Result information element. Bits Octets 6 5

13428 bits of Follow On Proceed Information

1343Follow On Proceed: DCS1900 Systems

1344For DCS1900, the values are:

1345Value Meaning

13460 Follow On Proceed Not Allowed

13471 Follow On Proceed

13482-255 Illegal

1349Table 4-39 Frame Offset [O]

1350The Frame Offset information element is the number of slots between the current slot and the beginning of the next frame . This tells the MS when the next frame begins, so it may increment the Frame Number synchronously with the BS while encrypting. This is required to support aggregated data and timeslot interchange in cipher mode.

1351The Frame Offset always reflects the correct value for the slot in which the CT message containing the Frame Offset information element is transmitted and received without error. This means that the sender must recompute the Frame Offset whenever it needs to re-send the CT message.

1352Bits Octets 6 5

13538 bits of Frame Offset

1354Table 4-40 HRef (Handover Reference)

1355The HRef (Handover Reference) information element is used to identify a specific handover process that has already been initiated by an Originating Handover Request sequence. Not all bits are significant. Bit s Octets 5 4

135648 bits of HRef (Handover Reference) 1 2 3 4 5 6

1357Table 4-40.1 HRef for DCS1900 Systems

1358In a DCS1900 infrastructure system, the HRef is assigned by the terminating Base Station Controller. Only one octet is significant.

1359Bits Octets

13608 7 6 5 4 3 2 1

13618 bits of HRef (Handover Reference) 1

1362Reserved 2

1363• 3

1364• 4

1365• 5 6

1366Table 4-41 Identity Data [O, N, I]

1367The Identity Data information element contains one of the identifiers of the MS as specified by the associated Identity Type. The precise length and format of the Identity Data information element will be determined by the Identity Type. If the length is less than the maximum 9 octets provided for the Identity Data information element, unused space will be at the end of the Identity Data information element (Octets 9, 8, ...) and all unused bits will be set to zero. Bits Octets

136872 bits of Identity Element 1 2 3 4 5 6 7 8 9

1369Table 4-42 Identity Type [O, N, I]

1370The Identity Type information element specifies which identity is being requested or supplied.

1371Bits Octets

13728 bits of Identity Type

1373value Identity Type

0 IMSI

1 TMSI

2 ESN

13773 UPT#

13784-255 Reserved

1379Table 4-34 LAC (Location Area Code)

1380See Zone.

1381Table 4-35 LAI (Location Area Identifier)

1382See Zone Table 4-43 Location [N, I]

1383The Location information element provides the identification of a specific element in the given table, The actual element identifiers are table dependent.

1384Bits Octets

13858

138616 bits of Location Identifier 1 2

1387Table 4-44 MCC MCC (Mobile Country Code)

1388The MCC (Mobile Country Code) identifies the County in which the network exists. In combination with the MNC it forms the PLMN and uniquely identifies a given network operator. It never appears as an independent information element in any Note

1389Bits Octets

13908 7 6 5 4 3 2 1

139116 bits of Mobility Country Code 1 2

1392Table 4-45 Message Length [M, N, I]

1393The Message Length field is to be filled in with the size of the message including the size field itself. The length of the message is measured in octets.

1394Bits Octets

13958 7

13968 bits of Message Length

1397Table 4-46 Message Type [O, M, N, I]

1398The Message Type information element defines the format of the rest of the message. The interpretation of the Message Type depends upon which particular Notes protocol is being discussed. Currently, the messages are sorted in alphabetical order by name. An effort is made, where possible, to maintain the same Message Type across all interfaces for common messages (e.g., Set Link) . Bits Octets 6 5 4

13998 bits of Message Type

1400Table 4-47.1 O Notes Message Type [O]

1401<img file="WO9713353A1_D0012.tif" /> If the most significant bit of the Message Type is set to 1, the message is a Transport Message. The seven least significant bits are used to specify the Transport Channel ID with which the data is associated.

1402Bits Octets

1403<img file="WO9713353A1_D0013.tif" />

1404Table 4-47.2 M Notes Message Type [M]

1405The Message Type information element defines the format for the remainder of the M Notes message.

1406Value (Hex) Description

140701 Diagnostic

140802 Initialize OTA

140903 Register

141004 Deregister

141105 Setup Link

141206 Release Link

141307 Connect Link

141408 Acknowledge

141509 Provision OTA

14160A Radio Status

14170B Link Status

14180C Data Message

14190D Power Off

14200E Circuit Switch Complete

1421OF Begin Traffic

142210 Acknowledge

142311 Authenticate

142412 Authenticate Reply Table 4-47.3 N Notes Message Type [N, I]

1425This Message Type information element defines the use of O-Notes and I-Notes. It defines the action of the message as well as the format of the message.

1426Type (Hex) Meaning

142700 Reserved

142801 Acknowledge

142902 Authenticate

143003 Authenticate Reply

143104 Base Status Request

143205 Base Status Response

143306 Cipher ACK

143407 Circuit Switch Complete

143508 Connect Link

143609 Deregister

14370A DTMF Start

14380B DTMF Stop

14390C Originating Handover

14400D Page

14410E Page Response

1442OF Register

144310 Registration Reject

144411 Service Information

144512 Set Cipher Mode

144613 Set Link

144714 Terminating Handover

144815 Terminating Handover Complete

144916 Transport

145017 Update ID

145118-7F Reserved for Notes RMT

145280 Diagnostic

145381 Diagnostic Result

145482 Download 83 Provision Table

145584 Read Table

145685 Reject

145786 Reset

145887 Reset ACK

145988 Table Data

146089-FF Reserved for Notes_OAM

1461Transport Message Types

1462If the most significant bit of the Message Type is set to 1, the message is a Transport Message. The 7 least significant bits are used to specify the Transport Channel ID with which the data is associated.

14638 7 6 5 4 3 2 1 Octets

1464<img file="WO9713353A1_D0014.tif" />

1465MNC (Mobile Network Code)

1466The MCC (Mobile Network Code) identifies the network within the country in which the network exists. In combination with the MCC if forms the PLMN and uniquely identifies a given network operator. It never appears as an independent information element in any Note. Test

14678 1 Octets

14688 bits of Mobile Network Code 1

1469Table 4-48 MS Capabilities [O]

1470The MS Capabilities information element defines the capabilities (features) present in the user station 102 (e.g., whether the user station 102 can receive a FAX or a data connection, whether the user station 102 is capable of ciphering, etc.) . Bits Octets

147116 bits of MS Capabilities 1 2

1472Network Periodic Control [M]

1473The Network Periodic Control information element specifies whether the MS OTA should perform automatic periodic network registration.

1474Octets

14758 bits of Network Periodic Control

1476Value Description (Hex)

147700 OTA should NOT perform network periodic registration

147801 OTA should perform network periodic registration

147902-FF Reserved

1480Network Service Request Data [0,M,N,I]

1481Octets

148216 octets of Network Specific Service Request Data 1 2

148324

1484Network Service Request Data for DCS1900 Systems

1485For DCS1900, this is the CM Service Request Network Service Response [0,M,N,I]

1486Bits 5 Octets

14873 octets of Network Specific Service Response Data 1 2 3

1488Network Service Response for DCS1900 Systems

1489For DCS1900, this is the CM Service Accept (octets in first two octets of the element) or the CM Service Reject (3 octets) .

1490Table 4-49 OTA Map [O]

1491The OTA Map information element describes the mapping of the OTA time slots to a particular user station 102. The format of this element is dependent upon the OTA Map Type information element in the same packet.

1492Table 4-50.1 Superframe Map:

1493Bits Octets

14948 7 6 5 4 3 2 1

149516 bits of slot mapping description 1 2

149616 bits reserved 3 4

1497Each bit in the superframe map indicates a time slot relative to the current time slot.

1498Octet Bit Time slot

14991 1 Same time slot, next frame 1 1 2 2 This frame, one time slot later

15001 3 This frame, two time slots later

15012 8 This frame, 15 time slots later Table 4-50.2 Subframe Map:

1502Bits Octets 6 5 4 3 2

1503Reserved Submultiplex 1

1504Reserved Frame Phase 2

1505Reserved Time lot Phase 3

1506Reserved 4

1507Submultiplex Rate The number of frames (Subrate) skipped between transmissions, plus one.

1508Frame Phase The number of frames skipped before the first transmission.

1509Time slot Phase The number of time slots skipped before the first transmission.

1510As an example, where the subrate is four, the frame phase is three, and the time slot phase is two, the user station 102 will wait three time frames 301 and two time slots 302 before the first transmission. Subsequent transmissions will occur in the same time slot 302 every fourth time frame 301.

1511Table 4-51 OTA Map Type [O]

1512The OTA Map Type information element identifies the type of OTA Map to follow.

1513Bits Octets

15148 7 6 5 4 3 2 1

15158 bits of OTA Map type OTA Map Type Meaning

15160 Unused

15171 Superframe

15182 Subframe

15193-256 Reserved

1520Page Group Activity [O]

1521The Page Group Activity information element indicates, in each paging roll, which of the 8 Page Groups - one corresponding to each bit in the information element -- are currently active, i.e., have an active page for at least one member MS of the page group. The BS and MS determine which Page Group a particular MS belongs to using the same algorithm used for the Leveling Bits field in the BS Capabilities Information element.

1522Bits Octets 5 4

1523Page Group Activity Bits

1524Paging/Broadcast Countdown [O]

1525The Paging/Broadcast Countdown information element will appear in the D Channel of all CT-GPO (General Poll) messages. It will indicate the time, in frames, until the next Frame in which a Paging Cycle or a Broadcast Cycle will start. The high order bit might be used to distinguish between a Paging Countdown and a Broadcast Countdown if such distinction proves desirable. Since this feature has not yet been implemented, this field will always contain 0-which is basically the same as "now. "

1526Bits Octets

1527Paging/Broadcast Countdown

1528PID [O_fM,N,I] Table 4-52 PID [O, M, N, I]

1529This information element is the personal identification number assigned to this user station 102. The low order byte defines the PID Type. The identifier is represented by the following 64 bits. The low order bit of the 64 bit number resides in Bit 1 of Octet 2 while the high order bit of the 64 bit number resides in Bit 8 of Octet 9.

1530If the PID Type is absolute, the PID absolutely and uniquely identifies the user station 102. The number is 72 bits long.

1531Bits Octets 6 5

1532PID Type 1

153364 bits of MS identification number 2

1534Table 4-53.1 PID Type

1535PID Type Meaning

15360 None

15371 Permanent PID

15382 Temporary PID

3 ESN

15404 UPT#

15415 HRef

15426-255 Reserved

1543In DCS1900 Systems, the Permanent PID associated with a user station 102 is the IMSI .

1544In DCS1900 Systems, the Temporary PID associated with a user station 102 MS is its TMSI. In DCS1900 Systems, the ESN associated with an user station 102 is its IMEI .

1545A PID of Type=HRef occurs in only limited cases:

15461. In a Specific Poll for the user station 102 from the (New) base station 104 during an Originating

1547Handover.

15482. In a Release Link (in either direction) during an Originating Handover (if the Originating Handover fails) .

1549A number which uniquely -- within the PID Type -- identifies the user station 102.

1550Table 4-54 PLMN (Public Land Mobile Network)

1551PLMN (Public Land Mobile Network

1552The PLMN (Public Land Mobile Network) uniquely identifies the operator of the network. It consists of the MCC and MNC. The PLMN occupies the first three Octets of the Zone Information Element; it never appears as a distinct information element in any Note.

1553Bits Octets

15548 7 6 5 4 3 2 1

155516 bits of unique MCC 1 2

15568 bits of unique MNC 3

1557Poll Type [O, M]

1558The Poll Type information element identifies the reason that the Poll was issued. Value Meaning

15590 Specific poll during Link Establishment

15601 Specific Poll during Handover

15612 Specific Poll during Lost Link Recovery

15623 Transaction Acknowledged

15634 Page Pending

15645 Cl Reassignment

15656-255 Reserved

1566Transaction Acknowledged is a special case of a Specific Poll during Link Establishment. It tells the MS that the transaction requested by the Transaction Hint in the CT-GPR is complete and that there is no need for further communication.

1567Page Pending is the only Poll Type allowed for a CT-PRO. It can also appear in a CT-SPO if there is a Page Pending when one of the other Poll Types would normally have been sent.

1568Table 4-55 Protocol [N, I]

1569The protocol information element identifies the signalin protocol

1570Bits Octets

1571Protocol Identifier

1572Protocol Type Protocol

15731 Notes RMT signaling protocol

15742 Notes OAM signaling protocol

15753-255 Reserved Table 4-56 Registration Info [0]

1576Registration Info contains information that is required by the System for registration. The precise format of the Registration Info depends upon the value of System Type.

1577Bits Octets

1578128 bits of Registration Info 1 2 3 4 5 6 7 8 9

157910 11 12 13 14 15 16 17

1580Table 4-56.1 DCS1900 Systems

1581For DCS1900 Systems, the Zone of the base station 104 on which the user station 102 was previously registered must be provided so the network 126 can locate the appropriate VLR for TMSI validation. Bits Octets

158240 bits (Old) Zone 1

15832

15843

15854

15865

158788 bits Reserved 6

15887

15898

15909

159110 11 12 13 14 15 16 17

1592Table 4-56.2 Bellcore Generic C Systems

1593For Bellcore Generic C Systems, the required registration information consists of the user station's UPT# and ESN.

1594Bits Octets

159564 bits of ESN 1 2 3 4 5 6 7 8 64 bits reserved 9

159610 11 12 13 14 15 16 17

1597Table 4-57 Registration Status [O, M]

1598The Registration Status identifies the user station's current registration status.

1599Bits Octets

16008 7 6 5 4 3 2 1

1601<img file="WO9713353A1_D0015.tif" />

1602Page Pend: value meaning

16030 There is no page pending

16041 There is a page pending (only valid in

CT-RCP)

1606Registration Status:

1607value status

16080 Not Registered

16091 Accepted

16102 Pending

16113-127 <TBD> Table 4-58 Registration Timer [0]

1612The Registration Timer information element sets the intervals between periodic re-registrations.

1613Bits Octets 5 4 3

1614Network Interval Base Interval

1615Table 4-58.1 Registration Timer: Base Interval

1616Value Interval

16170

16181

16192

16203

16214

16225

16236

16247

16258

16269

A

B

C

D

E

1632F Registration Timer: Base Interval

1633Value Interval

16340

16351

16362

16373

16384

16395

16406

16417

16428

16439

A

B

C

D

E

F

1650Table 4-59 Registration Type [O, N, I]

1651The Registration Type identifies the type of registration. Registration is the result of either a position change (geographic) or the expiration of the registration timer (periodic) .

1652Bits Octets

16538

1654Registration Type Registration Type: value type

16550 Base Geographic Registration

16561 Network Geographic Registration

16572 Base Periodic Reregistration

16583 Network Periodic Reregistration

16594 Power Up

16605 Request SBT

16616-255 Reserved

1662Table 4-60 Remaining Base Count [O]

1663The Remaining Base Count specifies the number of base station 104 in addition to the current one (the one specified in the CT-OH message containing the Information Element) for which the user station 102 intends to request an Originating Handover at this time.

1664Bits Octets

16658 7 6 5 4 3 2 1

1666Remaining Base Count

1667Table 4-61 Reserved [O, M, N, I]

1668The Reserved information element represents unused space. Al unused space is reserved for future use. All Reserved bits shall be set to zero by the transmitting station. All Reserved bits shall be ignored by the receiving station unless specifically defined otherwise.

1669Some Information Elements contain Reserved subfields. The same comments about reserved bits apply.

1670Table 4-62 Resource Request Data [O, M, N, I]

1671This 32 bit information element specifies the type of service being requested by the user station 102. Bits Octets

16728 7 6 5 4 3 2 1

1673DVS CRC-ARQ Symmetry Reserved 1

1674Bandwidth 2

1675DVP Transport Protocol 3

1676Reserved 4

1677DCS1900 ignores this information element in the N Notes RMT Service Request message.

1678Table 4-62.1 Bandwidth value meaning

16790-255 <TBD>

1680Table 4-62.2 CRC-ARQ value meaning

168100 Neither CRC nor ARQ in effect

168201 Reserved

168310 CRC in effect

168411 CRC and ARQ in effect

1685Table 4-52.3 DVS value meaning

168600 Reserved

168701 Voice service requested

168810 Data service requested

168911 Signaling service requested Table 4-62.4 Symmetry value meaning

169000 Symmetric Bandwidth

169101 Maximum MS bandwidth minimum BS bandwidth

169210 Maximum BS bandwidth minimum MS bandwidth

169311 Variable symmetry

1694Table 4-62.5 Transport Protocol value meaning

16950 8 bit transparency mode.

16961-255 Reserved for future use

1697Table 4-63 Service Provider [O, M]

1698This 16 bit information element, when present in a base-to- user signaling message, identifies the PCS service provider that operates the base station 105. When present in a user-to-base signaling message, it specifies the identification of the PCS service provider that the user station 102 wishes to use. The low order bit of this 16 bit element resides in Bit 1 of Octet 1 while the high order bit of this 16 bit element resides in Bit 8 of Octet 2.

1699Bits Octets

17008 5

170116 bits of unique Service Provider Identification number

1702Table 4-64 Service Type

1703The Service Type information element indicates the type of service being requested. value meaning oooo Null Service. Indicates that service resources are not yet being requested.

17040001 Normal call

17050010 Emergency (911) call

17060100 Short Message Service

17071000 Supplementary Service Activation

1708When this information appears in a N Notes RMT Handover Request message, the only legal values are Normal Call and Emergency Call. Furthermore, DCS1900 may not be able to provide this element, in which case it will default to Normal Call.

1709Set/Query [M]

1710The field will have a value of 0 to indicate that query operation is to take place and a value of 1 to indicate that a set operation is to take place.

1711Table 4-65 Slot Quality [O]

1712The Slot Quality information element identifies the radio frequency quality of the channel (time slot) in which the information element was received. To allow for flexibility, the meaning of the values is implementation specific.

1713Bits Octets

17148 7 6 5 4 3 2 1

17158 bits Slot Quality value Slot Quality

17160 <TBD>

1717255 Table 4-68 Surrounding Base Table (SBT) [O]

1718Bits Octets

17198 5 4

1720SBT Sequence # SBT Length

1721Base 1 Info Base 1 Code Index

1722Base 1 Frequency Index

1723Base 2 Info Base 2 Code Index

1724Base 2 Frequency Index

1725Base <SBT Length> Base <SBT Length> Info Code Index

1726Base <SBT Length> Frequency Index

1727Note that the table is of variable length. When it occurs in the CT-RCP message, it can store a maximum of 10 base index pairs, when it occurs in the CT-BAI message, it can store a maximum of 11 base index pairs.

1728Includes the frequency index and the code index for the <ith> surrounding base station 104.

1729Table 4-68.1

1730SBT: Base <i> Info

1731Information about Base <i> to help the user station 102 rank the base station 104.

1732Bits

17338 7 6 5 Meaning if Bit is Set

17340 0 0 1 This base station represents a Micro

1735Cell

17360 0 1 0 This base station is concentric with current base station

17370 1 0 0 Reserved

17381 0 0 0 Reserved Defines the number of base stations 104 which are contained in this SBT segment .

1739If the number of surrounding base stations 104 exceeds the maximum that can be held in the message (10 in the case of the CT-RCP) , this number will indicate the number of following messages (CT-ASIs) required to transmit the rest of the data. The number will thus serve as:

1740An indication of the existence of more surrounding bases than will fit in the table.

1741A unique identifier of which subset of base stations 104 are contained in this SBT. E.g., a value of zero means this is the only (or last) set of SBT entries. A value of 2 means that there will be two additional SBT segments following the current one.

1742Search Type [M]

1743The Search Type information element specifies the type of search being requested.

1744Bits Octets

17458 bits of Search Type

1746Value Description

17470 Specific PLMN

17481 Specific PLMN; if not found give PLMN List

17492 PLMN List

17503 Specific Zone

17514 Specific Zone; if not found give Zone List

17525 Zone List

17536 - 255 Zone List Search Time [M]

1754The Search Time Information element specifies the amount of time in milliseconds associated with a search request.

1755Bits Octets

175632 bits of Search Time 1 2 3 4

1757Search Time: Search Request

1758The Search Time information element specifies the maximum amount of time to perform the requested search.

1759Search Time: Search Confirmation

1760The Search Time information element specifies the actual amount of time spent performing the requested search.

1761Service Provider [O, M]

1762Table 4-69 System Type [O]

1763The System Type information element identifies the code set of the supporting infrastructure.

1764Bits Octets

1765System Type

1766value System Type

0 DCS1900

17681 Bellcore Generic C

17692-255 Reserved Table 4-70 TCID [O, M, N, I]

1770The TCID (Transport Channel ID) information element specifies the Transport Channel to which data in the message belongs.

1771Bits Octets

17728 7 6 5 4 3 2 1

1773Reserved 6 bits of TCID

1774When Transport Data is embedded in an 0 Notes_RMT_CT-TRA message, the TCID is embedded in the Message Type. In this case: bit 8 of the Message Type is set to 1. bit 7 is used for segmentation: it is set to 1 for the last segment of a Transport Message and to 0 for all other segments.

1775TCID Meaning

0 DCS1900 (SAPI 0)

17771 Reserved

17782 Reserved

3 DCS1900 (SAPI 3)

17804-63 Reserved

1781Defaults: When the Protocol in use is DCS1900, the TCID must be zero in all cases except when SMS traffic is being sent.

1782Table 4-71 Transport Data [O, M, N, I]

1783The Transport Data information element contains 19 bytes (152 bits) of application level data transferred between the user station 102 and the base station controller 105. The low order bit of the data resides in bit 1 of octet 1 and the high order bit resides in bit 8 of octet 19. The Transport Data information element may be larger (e.g., up to 260 bytes using LAPD) for interfaces other than the O-interface, which is restricted in size due to the length of the over-the-air information packet. Bits Octets

1784152 bits of Transport Data 1 2

178519

1786TC Data [M, N, I]

1787The TC Data Information element contains upper layer Transpor Channel data. If there are more than 19 octets of TC Data, the TC Data information element will be segmented into 19 octet Transport Data [O] segments for transfer over the 0 interface.

1788Bits Octets 4

1789<DC Data Length> octets of CTC Data 1 2 3 4 variable

1790Data Length [M, N, I]

1791The TC Data Length information element specifies the number of octets of TC Data to follow.

1792Octets <img file="WO9713353A1_D0016.tif" />

17935 3

179416 bits of TC Data Length Table 4-66 TCID [O, M, N, I]

1795The TCID (Transport Channel ID) information element specifies the Transport Channel to which data in the message belongs.

1796Bits Octets

17978 7 6 5 4 3 2 1

1798Network Type Application 1 Instance

1799When Transport Data is embedded in an 0-Notes_RMT_CT-TRA message, the TCID is embedded in the Message Type. In this case:

1800• bit 8 of the Message Type is set to 1 (in all other cases it is set to 0) .

1801• bits 1 -7 identify the Transport Channel for the message data.

1802TCID: Network Type

1803The Network Type Field consists of 3 bits which are used to identify a particular external network to which the CCT system is connected.

1804Value Meaning

0 DCS1900

18061 Reserved

1807• • • • • >

18086 Reserved

7 OAM

1810TCID: Application Instance

1811The Application Instance Field consists of 4 bits which are used to identify a particular Application Instance within the specified Network. For DCIS1900, the values are: Value Meaning

0 CC/SS/MM

18131 Reserved

18142 Reserved

3 SMS

18164-15 Reserved

1817or OAM, the values are:

1818Value Meaning

18190-15

1820Table 4-67 Traffic Type [M]

1821The Traffic Type information element specifies a type of B Channel traffic. (The values for Traffic Type are the same as those for the DVS field in the Resource Request Data Information Element. )

1822Bits Octets 5 4

18238 bits of Traffic Type

1824Value (hex) Description

182500 Reserved

182601 Voice

182702 Data

182803 Signaling

1829Transport Data [O]

1830The Transport Data information element contains 17 bytes (152 bit) of application level data transferred between the MS and BS. It will either contain the same data as the TC Data [M, N, I] information element or will contain a 19 byte segment of that data. Segmentation is performed in the MS-OTA and BS-OTA Bits Octets 5 4

1831152 bits of Transport Data 1 2

183210

1833Transport Retry Count [M]

1834The Transport Retry Count information element specifies the number of times to retry transmitting the data contained in the Transport_Req.

1835Bits Octets 5 4

18368 bits of Transport Retry Count

1837Transaction Hint [O]

1838The MS provides the Message Type of the first CT message it plans to send after it has acquired the link.

1839Transaction Hint Qualifier [O]

1840The MS provides additional information (not implicit in the Message Type) concerning the transaction it plans to perform.

1841Transaction Hint: RRQ (Registration Request) Qualifier

1842The MS will provide the Registration Type to allow the BS to know what kind of registration the MS will be requesting.

1843If the MS is requesting a Network Level Registration, the BS can use the MAP Information Elements in the CT-SPO message to put the MS directly into Slow Control Traffic.

1844If the MS is requesting a BS Level Periodic Registration, the BS can use the Cl and Cause Elements in the CT-SPO message to tell the MS that it is registered (the Cause IE) and that the BS does not expect to hear from it again for this transaction (Cl II set to zero) .

1845Transaction Hint: SRWQ (Service Request) Qualifier

1846The MS will provide the Resource Request Data Information Element to allow the BS to know whether this is a 911 call or a normal call and the minimum and maximum acceptable Channel Rates for the call. If the MS is requesting a 911 call and there is no channel available to put the call through, the BS can either:

18471. use the Map Information Elements in the CT-SPO to put the MS directly into Slow Control Traffic -- to wait for a channel to become available -- or 2. Use the Cl and Cause Elements in the specific poll to tell the MS that it is queued and will be paged as soon as there is a channel available (the Cause IE) and that the BS does not expect to hear from it again until it is paged (Cl IE set to zero) .

1848Transaction Hint: THR (Terminating Handover Request) Qualifier The MS will provide the Resource Request Data Information Element to allow the BS to know whether this is a 911 call or a normal call and the minimum and maximum acceptable Channel Rates for the call.

1849Transport Method [O, M, N, I]

1850The Transport Method information element contains data to specify bandwidth, protocol and other control information for

1851TRAUs. Its format differs based on the value of the DVS field in the Resource Request Data information element. If the DVS field indicates voice, then the format of Transport Method is: Bits Octets

18528 7 6 5 - m 3 2 1

1853Speech Algorithm Reserved 1

1854Reserved 2

1855Reserved 3

1856Reserved 4

1857If the DVS field indicates data, then the format of Transport method is :

1858Bits Octets 5 4

1859Network Rate Adaptation 1

1860Reserved 2

1861Reserved 3

1862Reserved 4

1863Transport Method: Speech Algorithm

1864Value Meaning

18650

18661

18672

18683

1869Transport Method: Network Rate Adaptation

1870Value Meaning

18710 GSM Transparent 9.6 kbps

18721 GSM Transparent 4.8 kbps

18732 GSM Transparent 2.4 kbps

18743 GSM Transparent 1.2 kbps

18754 GSM Transparent 600 bps

18765 GSM Transparent 1200/75 bps

18776 GSM Non-Transparent 12 kbps

18787 GSM Non-Transparent 6 kbps

1879Table 4-72 UPT [O, M, N, I]

1880This 80 bit information element is the Universal Personal

1881Telecommunications number that has been ranted to the subscriber operating the user station 102, and consists of 20 four-bit characters.

1882Bit s Octets 5 4 2 1

188380 bits of Universal Personal Telecommunications Number

188410

1885Table 4-73 Value [M]

1886The Value field contents are variable depending upon the item in the OTA which is being queried or modified.

1887Table 4-74 Zone [O, M, N, I]

1888The Zone and the Base ID combine to uniquely identify each base station 104 in the world. The precise format of the Zone depends upon the value of the System Type.

1889<img file="WO9713353A1_D0017.tif" />

1890A subset of the Zone, uniquely identifies the operator of the network. This portion is called the PLMN (Public Land Mobile Network) and, in the case of DCS1900 Systems, consists of the MCC and MNC. Table 4-74.1 Zone: DCS1900 Systems

1891For DCS1900 Systems, the Zone is the Location Area Identifier (LAI) ; it consists of a 16 bit Mobility Country Code (MCC) , an 8 it Mobility Network Code (MNC) and a 16 bit Location Area Code (LAC) .

1892Bits Octets

18938 7 6 5 4 3 2 1

189416 bits of unique MCC 1 2

18958 bits of unique MNC 3

189616 bits of unique LAC 4 5

1897Table 4-74.1.1 LAC

1898The LAC is an Location Area Code. The combination of the Base ID, MCC, MNC and LAC uniquely identify a given base station 104.

1899Bits Octets

19008 7 6 5 4 3 2 1

190116 bits of Location Area Code 1 2

1902Table 4-74.1.2 MCC

1903The MCC is a Mobility Country Code. The combination of the Base ID, MCC, MNC and LAC uniquely identify a given base station 104.

1904Bits Octets

190516 bits of Mobility Country Code 1 2 Table 4 -74 . 1 . 3 MNC

1906The MNC is a Mobility Network Code. The combination of the Base ID, MCC, MNC and LAC uniquely identify a given base station 104.

1907Bits Octets

19088 7 6 5 4 3 2 1

19098 bits of Mobility Network Code

1910The operation of Notes to communicate Information

1911Elements comprising user and signaling data within the communication system 101 can be explained by way of example with respect to the "Base ID" Information Element shown in Table 4-13. The Base ID is a 32-bit Information Element uniquely identifying within a particular message or Note a specific base station 104. The Base ID Information Element may be communicated within the communication system in O-Notes, M-Notes, N-Notes and I-Notes. Fo example, the Base ID Information Element is contained within the "Circuit Switch Complete" N-Note shown in Table 3-9, the "Circuit Switch Complete" M-Note shown in Table 1-7, and the "CT-CSC (Circuit Switch Complete)" O-Note shown in Table 2-10.

1912The operation of Notes to execute internal operations within the communication system 101 may be explained with respect to a process for switching communication paths for a mobile user station 102 within the communication system 101. Such a switch might occur, for example, when a user station 102 begins to leave cell 106 for a first base station 104 with which it is communicating, and begins to enter a second cell 106 for a second base station 104. In that case, it may be desired to handoff communication with the user station 102 from the first base statio 104 to the second base station 104.

1913Figure 13 is a flowchart setting forth a procedure for communicating the completion of a handoff of a mobile user station 102 between a first base station 104 and a second base station 104 in the communication system 101, wherein the two base stations 104 are connected to the same base station controller 105. In a first step 1310, the base station controller 105 initiates a process to switch the call connection from the first base station 104 to the second base station 104. In a next step 1320, the base station controller 105 communicates a Circuit Switc Complete N-Note across the N-Interface 620 between the base statio controller 105 and the first base station 104. The format for the Circuit Switch Complete N-Note is given in Table 3-9 and includes an Information Element containing the Base ID of the second base station 104. In a next step 1330, the base station 104 communicates a

1914CT-CSC (Circuit Switch Complete) O-Note across an O-Interface 610 between the first base station 104 and the user station 102. The format for the CT-CSC (Circuit Switch Complete) O-Note is given in Table 2-10. As shown in Table 2-10, the CT-CSC (Circuit Switch Complete) O-Note passes along the Information Element for the Base ID of the second base station 104.

1915The CT-CSC (Circuit Switch Complete) O-Note passes some common Information Elements from the Circuit Switch Complete N- Note, such as the New Base ID and HRef (Handover Reference Number) , to the mobile user station 102. By contrast, the base station 104 does not pass the PID (personal ID) Information Element to the mobile user station 102 in the O-Note, as the mobile user station 102 already knows its own PID. The PID which is contained in the N-Note is used by the base station 104 so that it can identify the particular user station 102 for which the base station controller

1916105 has completed a circuit switch. With the PID, the base statio 104 can determine the proper slot within its polling loop for transmitting the O-Note containing a CT-CSC (Circuit Switch Complete) message. Similarly, for each N-Note received from the base station controller 104 across the N-Interface, the base station 10 uses some Information Elements for its own internal operations, an passes other Information Elements along to the mobile user station 102. In a next step 1340, the mobile user station 102 communicates a Circuit Switch Complete M-Note across an M-Interfac 605 between the mobile communication transceiver in the user station 102 and an application end user hosted in the user station 102. The Circuit Switch Complete M-Note contains the Base ID Information Element. The Circuit Switch Complete M-Note also contains other Information Elements (e.g., BSC ID, Facility) added by the mobile communication transceiver 603 in the mobile user station 102. By contrast, the Circuit Switch Complete M-Note does not contain the HRef Information Element which is used by the mobile communication transceiver 603 to identify the particular handover request.

1917Layer Two O-Interface Definition

1918This section presents data link layer 424, Fig. 4A, the RF link protocol architecture of the O-Interface 610, Fig. 6. TDMA frame structures are defined and the underlying slot structure for TDD connection is presented. For example, a transmission, either from the base station or from the mobile user station, includes frame types and headers that are required to identify the specific purpose of that transmission. Additional information is provided to the receiving device that allows it to determine information bandwidth symmetry, whether error correction is applied and if the received transmission is part of an aggregated bandwidth connection. These processes are described in the following text.

1919Frame Format

1920Frame Format Normal

1921Each normal frame is composed of sixteen TDMA time slots where duplexing is accomplished by providing TDD within each TDMA frame. A channel composed of one time slot per frame provides one 9.6 kbps full duplex radio path for raw data. The time slots are not numbered. The numbers are shown in Table 5.1 for reference only. There is no frame mark transmitted over the air. Proper slot synchronization shall be performed by timing. Frame Format Extended Range

1922An extended range frame shall be composed of 8 TDMA time slots where duplexing is accomplished by providing TDD within each TDMA slot. The slots are not numbered. The use of this is deployment specific and is used in applications where range is extended (the excess time in each expanded time slot is used for Guard Time to allow larger propagation delays for extended range) . The numbers are shown in table 5.1 for reference only. There is no index associated with the frame. Proper slot synchronization is performed solely by timing. Both frame format normal and frame format extended range have the identical frame time (20 ms) .

1923Information Information Element Element

1924Slot 1 Slot 1

1925Slot 2

1926Slot 3 Slot 2

1927Slot 4

1928Slot 5 Slot 3

1929Slot 6

1930Slot 7 Slot 4

1931Slot 8

1932Slot 9 Slot 5

1933Slot 10

1934Slot 11 Slot 6

1935Slot 12

1936Slot 13 Slot 7

1937Slot 14

1938Slot 15 Slot 8

1939Slot 16 Table 5 . 1

1940Normal and Extended Range Frame Formats Channel Acquisition A mobile user station attempting to communicate with a base station shall seize at least one channel on that base station. This is accomplished by responding to a Base General Poll with a mobile user station General Response. The General Response for this mobile user station, the base station shall respond with a Specific Poll which contains the PID of this mobile user station. On reception of such a Specific Poll, the mobile user station may transition into the Traffic mode.

1941Until the mobile user station receives a Specific Poll containing its PID, the mobile user station shall not seize the channel and must wait a pseudo random time based upon the PID and then try again in a manner similar to the backoff procedure of ANSI/IEEE 802.3. When the base station is ready to assign a channel to the mobile user station and initiate communications with the mobile user station, the base station shall issue a Specific Poll packet containing the PID of the mobile user station.

1942Multiple Associated Signaling Time Slots per Frame

1943Normal time slot synchronization shall be accomplished by timing. Both the base station and mobile user station shall know which time slots have been assigned for communication. The mobile user station shall send its signaling information to the mobile user station in the first half of the TDD time slot; the base station shall send its signaling information in the second half of the TDD time slot. The mobile user station shall synchronize and shall maintain timing synchronization on the base station transmissions. The mobile user station shall maintain timing synchronization with the base station for up to one second in the absence of received base station transmissions.

1944If available, multiple time slots per frame shall be used for polling and signaling traffic. To accommodate this, the base station shall assign a temporary address known as the Correlative ID Cl, to the mobile user station on the first Specific Poll. This Correlative ID shall then be carried in further signaling traffic from the base station to the mobile user station. The mobile user station shall search for this ID in all traffic. The mobile user station can then respond to any signaling traffic time slot containing this Correlative ID. Unused Correlative IDs shall be maintained in a pool by the base station. When communication has ended between the base station and mobile user station, the Correlative ID shall be returned for reuse. Any available time slot may be used by the base station to continue signaling communications with the mobile user station. The last time slot used by the base station for signaling traffic will become the first time slot for bearer traffic use unless otherwise specified by slot mapping information given to the mobile user station by the base station. If the base station returns to signaling traffic at a later time on the current channel, the Correlative ID will still be effective, and the base station may use any available time slot for further control traffic.

1945Asymmetric Channels

1946Traffic flow between the base station and mobile user station may be either symmetric or asymmetric. The total number of bits per TDD time slot shall remain constant in either case. The flow shall be controlled by the base station acting upon the Bandwidth Request bit in the mobile user station to base station traffic header. The normal flow is symmetric with an equal number of bits (except for the header bits) assigned in each direction. The Bandwidth Grant bits in the header of the base station to mobile user station traffic channel shall establish the actual number of bits to be used in the next time slot of the channel.

1947The base station shall assign TDD time slot bandwidth (number of bits) using the following algorithm:

19481. If only the base station (BS) requires additional bandwidth, then the base station shall be granted the additional bandwidth for the next time slot assigned to that mobile user station. 2. If only the mobile user station (MS) requires additional bandwidth, then the mobile user station shall be granted the additional bandwidth for the next time slot assigned to that mobile user station. 3. In all other cases, symmetric bandwidth shall be granted for the next available time slot assigned to that mobile user station.

1949Broadcast Channels The asymmetry of the channel may be taken to its logical extreme by granting the entire bandwidth of each time slot to the base station to produce a broadcast channel. The nature of this channel shall be indicated by the Bandwidth Grant bits in the base station time slot header (they apply to the next time slot in the channel) . Multiple simultaneous Broadcast Channels shall be supported. During broadcast, the bits normally used for the D- Channel shall be used as a broadcast identifier. Since this occurs in the same position as the Correlative Identifier, the difference in usage is signaled by the Bandwidth Grant bits.

1950Super Channel

1951The ability to assign multiple time slots in the frame may be negotiated for and assigned to an individual mobile user station. The negotiation may take place at any time via signaling traffic. The assigned TDD time slot, if available, shall be communicated by the base station to the mobile user station via the OTA Map Type and OTA Map information elements. Channel synchronization shall be maintained by the mobile user station based on frame timing.

1952The handover procedure shall account for the multiplicity of time slots per channel assigned to the transferring mobile user station. A base station shall have the appropriate number of time slots available to become a candidate as a terminating base station for handover. The time slots need not be available in the same positions in the frame as those in the originating base station. Logical Sub Channel

1953A mobile user station need not be granted a time slot in every frame. Time slots may be granted in frames separated by an integral number of intervening frames. The maximum limit on the separation of frames allocated to a single mobile user station is one time slot every 25 frames or every 0.5 seconds. This would yield a channel with a raw full duplex rate of 384 bps.

1954Multiple Mode Traffic

1955A single mobile user station may have multiple connections established through the Base Station to the network via multiple channels. One channel may, for example, be assigned to audio traffic while other channels are devoted to data traffic.

19560_Notes_RMT Protocol: Packet Formats

1957There are two basic types of OTA Packets:

19581. Signaling Packets, which are used to transfer control information between the base station and the mobile user station, and

19592. Bearer Packets, which are used to transfer Voice and Data Traffic between the base station and the mobile user station.

1960Two packets are transmitted during each TDD time slot, one from the mobile user station to the base station and one from the base station to the mobile user station. Each packet is formatted to be entirely self-contained within its portion of the slot. Error correction and detection is achieved by use of the Frame Check Word (FCW) which appears in all packets. Error recovery of individual packets is left to the higher Protocol handlers of network layer 422, although the ARQ mechanism may be optionally employed.

1961The only difference between the Packets sent by the Base Station and those sent by the Mobile Station is the size (and format) of the Header: 23 bits in Packets originating from the base station and 17 bits in Packets originating from the mobile user station. Data is not transmitted over-the-air in octets (multiples of 8 bits) . The lengths of the information elements shown in the following formats and packets are the lengths seen by the controlling software.

1962Signaling Packet Format

1963Signaling Packets are always symmetric, thus there are no High or Low Bandwidth Packet Formats. (It is possible that asymmetric signaling packets will be defined in the future.)

1964Information Element Length in Bits

1965Header (17 or 24 23 bits)

1966D Channel 8

1967B Channel 160

1968Reserved for FEC 32

FCW 16

1970<Total Bits in mobile user station> 240

1971Bearer Packet Format

1972Bearer Packets are used to transmit Voice or Data traffic end-to-end through the CCT system. There are three varieties of Bearer Packets: high bandwidth, low bandwidth and symmetric bandwidth. (From the base station, there is also a broadcast variety of Bearer Packet. )

1973When the OTA link is symmetric, both the base station and the mobile user station will transmit a symmetric bandwidth packet. When the OTA link is asymmetric, one side will transmit a high bandwidth packet and the other side will transmit a low bandwidth packet. Which side transmits which size packet will be determined by the Symmetry Bits in the base station Header transmitted during the previous time slot in which the base station and mobile user station exchanged packets. High Bandwidth Packets

1974High Bandwidth Packets are used to transport large amounts of bearer traffic or signaling traffic between the base station and the mobile user station.

1975Information Element Length in Bits

1976Header (17 or 24 23 bits)

1977D Channel 8

1978B Channel

FCW 16

1980Layer 3 Air Interface Description

19810_Notes_RMT Protocol: Control Traffic Packets

1982This section supplies the message formats that are intrinsic to network layer 422, Fig. 4A, Layer 3 Air Interface protocol architecture of O-Interface 610, Fig. 6. These formats are described in detail to include the definition of the message, the required number of bits or field size and application of the message. This section describes the functions that are one level above the frame and slot structure but include the critical components that provide differentiation between types of traffic. Call flow diagrams are dependent on the message set described in this section.

1983Level 3, network layer 422 signaling information shall be contained in data packets. The details of these packets are given in the following section. Each signaling message shall be contained in one data packet .

1984Note that the data portion of all Control Traffic Packets is limited in length to 160 bits (20 octets) . The remaining 32 bits (4 octets) are specifically reserved for future use by a FEC (Forward Error Correction) mechanism if such a mechanism proves necessary.

1985Special Interpretation of D Channel Information

1986Since the CT-GPO is to all listening Mobile Stations, the D Channel does not contain a Cl as it does for other signaling 151 messages. Rather, it will be used for the Paging/Broadcast Countdown Information Element.

1987Special Interpretation of D Channel Information As with all CT messages, the D Channel in the CT-GRP messages is used for the Cl (Correlative ID) . For an MS acquiring a link for the first time (i.e., no currently active link) , the value of this field will be zero. This includes both MSs without any active link plus those MSs (in the future) which are acquiring an addi tional active link. For an MS which currently has an active session, and which is acquiring a link as part of lost link recovery or to perform signaling without interrupting its bearer traffic, this field will contain the current Cl.

1988Special Interpretation of D Channel Information The D Channel in the CT-SPO message is used for the Cl (Correlative ID) . Normally, this is how the MS learns the Cl's value for the first time. There are cases where the BS has learned all it needs to know from the Transaction Hint given by the MS in its CT-GPR message. In these cases, the BS will respond to the MS with a CT-SPO message whose Cause information element (IE) provides the requisite information to the MS to complete the transaction. The Cl of this IE will be zero, which the MS interprets as meaning that the BS does not expect to hear from it again.

1989The BS will use the Correlative ID IE in the CT-SPO message to either assign a new Cl to the MS, or to tell it (with a value of zero) that it does not want the MS to respond again (except for a CT-ACK) . The most likely reasons for a Cl of zero is that the BS has all the information it needs for a BS Periodic Registration or for 911 queuing, but there may be other reasons (which will be identified in the Cause information element) .

19900_Notes_RMT Protocol: Using The D-Channel

1991The D-Channel is a one-byte element of the OTA Packets which is used as a Secondary Signaling Channel for slow (or very short) signaling. 152

1992D-Channel Data Rate

1993Channel Rate Equivalent Raw D-Channel D-Channel in Slots/Frame B-Channel Data Data Rate Data Rate

1994Rate (bits/second) (octets/ (bits/ second second)

19951/32 300 1.88 12.5

19961/16 600 3.13 25

19971/8 1200 6.25 50

19981/4 2400 12.5 100

1999« 4800 25 200

20001/1 9600 50 400

20012/1 19,200 100 800

20023/1 28,800 150 1,200

20034/1 38,400 200 1,600

20045/1 48,000 250 2, 000

20056/1 57,600 300 2,400

20067/1 67,200 350 2,800

20078/1 76,800 400 3,200

20089/1 86,400 450 3,600

200910/1 96,000 500 4,000

201011/1 105,600 550 4,400

201112/1 115,200 600 4,800

201213/1 124,800 5,200

201314/1 134,400 700 5,600

201415/1 144,000 750 6,000

201516/1 153,600 800 6,400

2016D-Channel Usage

2017When the main circuit is used for Signaling, the D-Channel s used for:

2018• Correlative ID: In all Signaling Traffic (CT- messages) except for General Polling Messages.

2019General Polling Messages -- i.e., CT-GPO and future messages -- do not contain a PID (or a Cl) because they are addressed to multiple MSs.

2020• Reserved: The D-Channel in General Polling Messages is reserved for future use. Possible use includes a count down event timer to alert all mobiles to the beginning of an event such as a Paging loop or a broadcast message sequence, and b) a grouping message which identifies a group of MSs for which the General Polling Message is targeted.

2021When the main circuit is used for Bearer Traffic, the D- Channel is used for:

2022• Transport Notes whose channel preference includes the D-Channel. These notes generally contain information which is not critical, e.g., SMS messages.

2023• Very short OTA signaling transactions such as a MS's request for a TSI or a brief ASR/ASI type transaction: e.g., containing the MS's distance from the BS.

2024D-Channel Protocol When the main circuit is being used for Bearer Traffic, all byte values in the D-Channel are legal as data. There are a few byte values which also have meaning as signaling information.

2025Value Meaning (hex)

2026FF Filler

2027FE Escape

2028FD SOM (Start-of-Message)

2029FC EOM (End-of-Message)

2030FB Instant Request: TSI

2031FA Instant Request : Separate Signaling Channel

2032Filler

2033The Filler byte is send in the D-Channel whenever there is nothing else to send. The ARQ MSG# is never bumped for it and it is never re-sent in response to the ARQ NAK unless there is nothing else to send.

2034Escape The Escape byte is sent in the D-Channel as an immediate prefix to any signaling byte -- including the Escape byte -- which appears in the data being sent.

2035SOM (Start-of-Message) The SOM Byte is sent to signal the beginning of a new

2036Transport Note. It is required because of the ability to switch between the D and B channels for the transmission of the Transport Note. The character immediately after the SOM will be any legal 0_Note Message Type; if the Message Type is one of the special signaling bytes, it will be prefixed with the Escape byte.

2037EOM (End-of-Message) There EOM byte signals the end of a message. It will be followed by one of the following: • a Filler byte,

2038• an SOM signaling the beginning of a new message,

2039• one of the Instant Request signaling bytes.

2040Instant Request: TSI The IR (Instant Request) : TSI byte is a "single-byte message" which is used to request a Time Slot Interchange. Since it is a single byte in length, it does not require either an SOM or an EOM.

2041The IR:TSI command is used by the MS to ask the BS to perform a TSI; the BS's reception of the IR:TSI command is confirmed by the ARQ bits of the BS's response message. The BS's acceptance of the TSI request is evidenced by the appearance of either a non-zero Next Slot Pointer in the header and an IR:TSI byte in the D-Channel (if the circuit is a single channel) or by the appearance of a CT-STL message and the MS's

2042Cl in the D-Channel (if the circuit is either sub-rate or super- rate) . The BS can initiate a TSI by the same mechanism -- a non¬ zero Next Slot Pointer in the header and an IR:TSI byte in the D-Channel of the same packet.

2043Instant Request: Separate Signaling Channel

2044This is a "single-byte message" which is used to request a Separate Signaling Channel. Since it is a single byte in length, it does not require either an SOM or an EOM.

2045The IR:Separate Signaling Channel command is used by the MS to ask to BS to establish a separate signaling channel so that the MS may perform some higher speed signaling without preempting the existing B-Channel. The BS will grant the request if it can, in which case it will send a non-zero Next Slot Pointer in the header and an IR:Separate Signaling Channel byte in the D-Channel of the next packet.

2046The BS can also initiate the Separate Signaling Channel by the same mechanism -- a non-zero Next Slot Pointer in the header and an IR:Separate Signaling Channel byte in the D-Channel of the next packet.

2047Data

2048The 0_Note Message Type byte will be followed by one or more bytes of data, comprising the information elements of an O note. Whenever one of the signaling bytes appears as a data bye, the segmenter will prefix the byte with an Escape byte. All zero bytes at the end of the note -- the Reserved bytes⁵--will be omitted. It will be the responsibility of the D- Channel Segmenter to remove the bytes on transmission and to reinstate them on reception, if appropriate. Note that zero suppression will not occur for CT-TRA messages since there are no Reserved bytes.

2049Encryption

2050If encryption is enabled on the D-Channel, it will occur on the date (except the Message Type) before the note is presented on the D-Channel Segmenter. Byte stuffing (i.e., the process of prefixing Escape bytes to ambiguous data bytes) is performed on the encrypted data. 156

2051Delayed or No Response To An IR (Instant Request)

2052The MS must be prepared for the possibility that an IR will ot be immediately responded to for two reasons : 1. The BS does not respond to the request because it does not have the resources to satisfy the request. 2. The BS doesn't have time to process the request before it must respond. It may still honor the request during the next slot. If it does so, it will have the same effect as if the BS had initiated the request; it will be effective when the MS honors the Next Slot Pointer by responding in that slot. If the MS does not respond, the BS must assume that the MS did not hear it and proceed accordingly.

2053It is, of course, possible that the last non-Reserved byte(s) in the 0_Note will be zero. This will not matter, since they will be recovered during re-segmentation.

2054If the BS doesn't have time to respond immediately but prepares to do so next slot, and the MS decides to preempt the bearer during the next slot, the BS will interpret the second request as a duplicate request and will ignore it. It will appear to the MS that the BS had responded to its second request immediately. 3. The MS D-Channel Segmenter did not send the request because the D-Channel is in the process of sending an Escape sequence. Specifically, an Escape was sent in the D-Channel last slot and the IR request cannot be sent this time or else it would be treated as a data character and the true data character would be treated as a command or as data when it appeared, unescaped, in the next slot. If an Escape sequence is in progress, the D-Channel Segmenter will notify the MS OTA -- it will not save the command to send next slot -- and the MS OTA will either re-send the request next slot or will adopt another strategy (e.g., sending a control message in the B-Channel) . 4. If a D-Channel command is required as part of the BS's response and if the BS D-Channel Segmenter is in the process of sending an SOM or escape sequence. If this is so, the D-Channel Segmenter will notify the BS OTA -- it will not save the command to send next slot -- and the BS OTA will either re-send the response next slot or will adopt another strategy (e.g., sending a control message in the B-Channel) .

2055Procedures &amp; Algorithms

2056This section describes procedures and algorithms which are integral to the OMNI_Notes protocols (common to 0,M,N,I,) .

ARQ

2058The ARQ, Automatic Repeat Request, mechanism provides a first level of protection against over-the-air errors. It relies on three one-bit fields in -the header of each 0_Note packet :

20591. B-Channel Enable,

20602. ACK and

20613. MSG#. The D-Channel is always protected by ARQ. If the B-Channel Enable bit is set, then the B-Channel is also protected by ARQ. Other than determining the Channels protected, the bit has no impact on the ARQ mechanism. The term message designates-for this discussion of the ARQ mechanism -either the D-Channel or both the D- and B-Channels as determined by the B-Channel Enable bit.

2062If the incoming packet-the entire packet, not just the message-is error free, the receiver will set the ACK bit in its outgoing packet. If the incoming packet contains errors, of if there is no packet received when one is expected, the receiver clears the ACK bit-sets the NAK value-in its outgoing packet.

2063If the incoming packet is error free, the receiver compares the MSG# of the incoming message with the MSG# of the previously received message; if they are the same,the receiver ignores the new message (with the exception that if the new message is a CT- HLD, its SCT parameters will be checked for OTA mapping information) .

2064If the incoming packet is error free and the ACK bit is set-indicating that the sender received the last message from the receiver without error, the receiver will complement-i .e. , increment modulo 2-the MSG# bit and send the new message (i.e., the next message it has to send) in its outgoing packet.

2065If the incoming packet is error free and the ACK bit is cleared-indicating that the sender encountered some sort of error in the last message from the receiver-or if the incoming packet is not error free, or if no packet is received, the receiver will resend the same message and MSG# that it sent last time in its outgoing packet . In the context of ARQ processing, the CT-HLD 0_Note requires special handling. It is basically a filler and is transparent to ARQ; aside from being used to enter or change SCT it does not contain significant information and so it never needs to be retransmitted. The MSG# bit is not complemented when CT-HLD messages are sent. (A CT-HLD message will never be sent when there is another message outstanding; this includes the case where the message is outstanding because it was not successfully ACKed in the ARQ response from the receiver. Thus, the receiver can ignore the CTHLD-after checking if for SCT information.) When the receiver would normally resend the old message and the last message it sent was a CT-HLD, it will transmit a new message if one has arrived. It will complement the MSG# bit for the new message; the receiver will see the message as a new message to the last message received before the CT-HLDs were sent. In general :

2066• the setting of the ACK bit in the outgoing packet is determined by the error status of the incoming packet;

2067• the setting of the MSG# and the content of the message in the outgoing packet are determined by the state of the ACK bit in the incoming message;

2068• whether the incoming message-assuming it was error free-is accepted or ignored is determined by the value of the MSG# bit in the incoming packet (and how it compares with the MSG# bit of the previously received packet) . 159

2069Channels and Data Rates

2070In a time division multiplexing system, a normal channel is composed of one slot per frame-i.e., the same slot each frame concatenated together over time. A channel supports a 9.6 KBPS circuit; the rate used for normal voice calls. The OMNI_Notes protocols support different circuit rates-both faster and slower-as we11.

2071For certain applications it is desirable to transmit signalling information at faster or slower speeds than those available with one channel per time slot for each mobile station. Faster rates are achieved by combining 2 or more slots --the same slots each frame-- into a circuit. This mechanism is called Aggregated Slot Traffic (AST) .

2072Slower rates are achieved by skipping frames within a channel. These unused slots can be assigned to another MS, allowing the BS to interleave multiple MSs, each broadcasting at a slow rate, into the same channel. This mechanism is referred to as Slow Slot Traffic (SST) .

2073Both AST and SST are controlled by the BS. Circuit rates for Bearer Traffic are negotiated between the MS and Network

2074Applications and then requested of the OMNI pipe; circuit rates for Signaling Traffic are determined solely by the BS, although they may be requested by the MS. Once the rate has been determined, the BS assigns the appropriate OTA and backhaul resources and communicates these assignments to the appropriate entities within the OMNI pipe.

2075Note that the circuit rates and slot assignments for the Bearer and Signaling portions of a call are independent. For example, even though a call may be assigned a specific set of slots for AST Bearer Traffic, Signaling Traffic for the call may be either carried as SST or it may be carried as AST using a different set of slots.

2076Bearer Traffic Once the BS has assigned the resources for the Bearer portion of a call, it will communicate the Backhaul Map to the BSC via the Service Information message and the OTA Map to the MS via the CT-STL message. Since circuit rates other than 9.6 KBPS are normally used for data the descriptions of super- and sub-rate circuits are presented using data call terminology. This is not a protocol requirement, AST or SST circuits may be used for voice at the implementers option, although new vocoder algorithms will be needed on both the MS and the Network side.

2077Aggregated Data SubRate Data Signaling Traffic

2078Two types of Signaling Traffic are supported: Fast Control Traffic (FCT) and Slow Control Traffic (SCT) ; there is no normal rate as there is for Bearer Traffic. The "normal" Control Traffic rate is basically FCT with a Next Slot Pointer of zero (same slot, next frame) .

2079There are no special backhaul resources assigned for Signaling Traffic-Signaling Traffic is transported through the single signaling channel which was set up when the BS and BSC initially established communications, so there is no backhaul assignment to communicate to the BSC.

2080The OTA resources assigned for Signaling Traffic are communicated to the MS via a mechanism dependent upon the type of signaling. FCT is dynamic. That is, there is no constant signaling rate, and the slot assignment for the next exchange is communicated to the MS via the Next Slot Pointer in the BS packet header. For SCT, the slot assignment is static (relatively) and is communicated to the MS via the CTSPO message when the circuit is established, or via a CT-HLD message if SCT is established or changed after the circuit is established. The Next Slot Pointer in each message does point to the next slot assigned for SCT, but the SCT rate may not be changed via this mechanism.

2081Both types of Control Traffic depend upon two features of the OMNI_Protocol : The Cl information element (which is essential for recovering from a missed packet) and the Next Slot Pointer (which tells the MS when the BS is expecting it to transmit) . ARQ functions normally for both FCT and SCT. 161

2082Fast Control Traffic

2083Fast Control Traffic ( FCT) is a method of accelerating signaling over the 0-Interface Cl. It is of maximum value for time-critical operations such as handovers; it is of limited use when the signaling extends beyond the 0 Interface in either direction.

2084FCT relies on several mechanisms: the Next Slot Pointer, the Cl and the ARQ. FCT differs from Bearer AST in that it is very dynamic rather than being static (occurring in predetermined slots) . In each BS transmission, the packet header identifies the next slot in which the MS shall transmit. This is all there is to FCT when there are no errors.

2085Error Recovery BS loses MS Message

2086When the BS detects an error in an FCT message from the MS, it uses the standard ARQ procedure to recover.

2087MS loses BS Message When the MS detects an error in an FCT message from the BS, it cannot use the ARQ procedure because it has an additional problem: it does not know which slot to transmit in because it didn't receive a Next Slot Pointer. Instead, it goes into a mode where it scans every packet transmitted by the BS, looking for a packet containing Packet Type = Signaling and the Cl which was assigned to the MS at the beginning of the session. When it finds the packet, it knows that the BS did not receive a message from it, since it did not transmit in the first part of the slot. Thus, the BS will, using the ARQ algorithm, have re-sent the message that the MS missed. This also gives the MS a new Next Slot Pointer, so it now knows where to respond.

2088Since the MS also did not receive the ARQ bits in the lost packet, it does not know whether the BS received its last packet or not. (The ARQ bits in the current packet tell the MS that the BS did not receive the packet which the MS already knows it didn't send.) However, the MS has two pieces of information from which it can make some inferences :

20891. it knows whether ft sent an ACK or NAK in the last message, and it knows whether the MSG# just received from the BS matches the last MSG# received.

2090The following table shows how the MS can determine whether to re-send old message or re-send new message based on these two pieces of information.

2091ACK /NAK MSG# Did BS receive last message? last match?

2092NAK Different Not a possible outcome: if it occurs, resend last message and report protocol violation to OAM&amp;P.

2093NAK Match Don't know: re-send last message

2094ACK Different Last message was received, send new message

2095ACK Match Last message not received, re¬ send last message

2096Having the new Next Slot Pointer and knowing whether to send a new message or resend the old message, the MS can now recover correctly from the lost message.

2097Slow Control Traffic

2098Slow Control Traffic ( SCT) is a method of supporting a low- rate continuous signaling link. This provides the ability to multiplex several MSs involved in non-time-critical signaling sequences onto a single OTA channel to conserve bandwidth. This mechanism is used for registration and may be used for other activities if desired.

2099SCT is a special case of Slow Slot Traffic (SST) . The BS can assign the MS to a subframe slot where the BS and MS both skip n (l≤ n . ≤ 31) frames between timeslots. This allows the BS to interleave several MSs which are in SCT Mode on the same timeslot.

2100BS Procedures

2101Timeslot Management is the key to both FCT and SCT. If the BS does not wish to implement the more complex Timeslot 163

2102Management algorithm required for FCT or SCT, it can simply insure that Frame SubRate = 0, Frame Phase = 0 and Slot Phase = 0 .

2103There are a couple of comments concerning SCT, below. • If the Service Type of the Link indicates that a voice or data circuit may be established, it might be advisable to not enter SCT mode. Otherwise a call might be lost because there were no longer resources available when it is time to leave SCT mode. This would work for a single slot call; it would not solve the problem for an aggregated data call.

2104• If the BS recognizes a registration, CT-RRQ, it should attempt to enter SCT mode.

2105• If a hold sequence proves lengthy, the BS might enter SCT at a fast rate-say every second frame-and then gradually slow the rate as the cumulative number of sequential CT-HLDs increases.

2106MS Procedures To support SCT, the MS must:

2107• Recognize and record the Cl during Slot Acquisition and be capable of using it during error recovery, as it does for FCT.

2108• Handle non-zero values of Frame SubRate , Frame Phase and Slot Phase and use them for Control Traffic, just as it does for Bearer Traffic.

2109Entering SCT Mode

2110SCT Mode can be activated only by the BS and only by sending an OTA Map specifying the desired rate in a CT-SPO or

2111CT-HLD message. When the BS, by whatever heuristics it uses, decides it will be beneficial to put the MS into SCT, it will set the Frame SubRate and, optionally, the Frame Phase and Slot Phase fields in the OTA Map information element to non-zero values. The Next Slot Pointer in the header of the CT-SPO or

2112CT-HLD message continues to point to an FCT slot. The MS and BS do not enter SCT Mode until the MS has signaled its acceptance of the SCT parameters by echoing them back to the BS in a CT-HLD message in the next FCT signaling slot. (If Frame Phase = 0 it is legal for Slot Phase and Next Slot Pointer to point to the same slot, but until the BS receives the acknowledging CT-HLD message from the MS, it does not enter SCT mode.) The SCT parameters -Frame SubRate, Frame Phase and Slot Phase-are relative to the slot in which they are transmitted, even though SCT mode does not take effect until the MS has acknowledged.

2113When the BS receives the acknowledging CT-HLD message, it will respond with a CT-HLD in its portion of the slot and enter SCT mode. The MS will interpret the ARQ bits of this message from the BS to determine whether the BS received the MS's acknowledging CT-HLD. If the ARQ bits indicate success, the MS will also enter SCT mode. If the ARQ bits do not indicate success, or if the MS does not receive the message without error, it will begin SCT Error Recovery.

2114Maintaining SCT Mode Once SCT Mode has been entered, the MS and BS will maintain SCT mode by exchanging signaling messages at the rate specified by the Frame SubRate. Each CT-HLD message exchanged shall contain the same value of Frame SubRate and the Frame Phase and Slot Phase fields will equal zero. In particular, each CT-HLD message contains the sender's current understanding of the SCT rate. If the values are not the same, it means that the transmitting side is requesting a change of SCT mode. At some time while the MS and BS are in SCT, one or the other of them will have information (other than CT-HLDS) to transmit. These CT messages can be transmitted in SCT mode, in fact, the possibility exists that there will not be sufficient resources (time slots) available to exit SCT.

2115Changing SCT Rate Once SCT mode has been established, the Frame Phase and Slot Phase fields in subsequent CT-HLD messages will typically be zero and the Frame SubRa te will typically remain at the same value it had when SCT mode was established. It is possible that the BS may decide to either change the rate of the SCT while remaining within the same slot, or to shift the MS to another location in its slot map. It will do this by manipulating the values of the Frame SubRate, Frame Phaεe and Next Slot Pointer fields. As with initial entry to SCT mode, the change will not take place until acknowledged via a CT-HLD reflecting the new rate-by the MS. This has the implication that the BS must maintain both slot maps until it is clear that the MS has accepted the change.

2116Exiting SCT Mode

2117In order for the BS and MS to exit SCT mode, there must be resources available-i .e. , there must be an available slot or slots that can be used for normal or FCT signaling. The balance of this section assumes that sufficient resources are available, see the discussion of SCT Error Recovery for system behavior when there are not sufficient resources to exit SCT mode.

2118If the BS determines that it is time to exit SCT mode, it will transmit a CT-HLD map with all of the SCT parameters-Frame SubRa e, Frame Phase and Slot Phase-set to zero. When the MS acknowledges-with a CT-HLD message with the SCT parameters also set to zero-the BS will transmit whatever signaling message it has to transmit in the same slot as the MS's acknowledgment; the Next Slot Pointer in this message will indicate a slot within the next frame and the signaling will revert to FCT signaling.

2119MS Influences

2120Although the BS controls SCT Mode, the MS is capable of requesting SCT entry, exit or rate change:

2121If the MS and BS are in FCT mode, the MS can request entry of SCT mode by transmitting a CT-HLD message with a non-zero value of Frame SubRate. The MS will, if possible, honor the MS's request by invoking SCT at a rate as close as possible to that requested by the MS.

2122If the MS and BS are in SCT mode, the MS can request a rate change by transmitting a CT-HLD message with the desired Frame SubRate (different from the current frame subrate) ; it may not request a change in Frame Phase or Slot Phase. The BS will, if possible, honor the MS's request by initiating a change to a new subrate as close as possible to that requested by the MS.

2123If the MS and BS are in SCT mode, the MS can request exit from SCT mode by transmitting a CT-HLD message with the zero value for Frame SubRate . The MS will, if possible, honor the MS's request by exiting SCT.

2124In all cases, the MS will know whether the BS has accepted or rejected the request by the values of the SCT parameters received in the next error free CT-HLD message. The requested rate will not become effective until the MS has acknowledged the change by echoing the SCT parameters to the BS in its next CT- HLD message.

2125Error Recovery

2126Because of the potentially long intervals between message exchanges while in SCT, special error recovery procedures are required when an error occurs in SCT mode.

2127BS loses MS Message

2128If the BS loses an MS message while attempting to establish SCT mode, it will continue with the attempt to establish SCT mode. Repeated lost messages will eventually prompt normal Lost Link Recovery. If the BS loses an MS message during SCT mode, it will

2129'increment its leaky bucket" and attempt another transmission during the next assigned SCT slot. If the leaky bucket overflows, it will implement normal Lost Link Recovery and begin transmitting Specific Polls for the MS in the assigned SCT slots until its Lost Link Recovery timer expires. The OTA Map in the CT-SPO message will determine the signaling rate to be used when the link is recovered.

2130MS loses BS Message If the MS loses a message while attempting to establish SCT mode, it will attempt to recover using the same technique defined for FCT; it will begin scanning for CT messages containing its Cl . If it sees such a message, it can respond in the slot indicated by the Next Slot Pointer in the CT message. If it does not see such a message after a reasonable amount of time-the amount shall be provisionable with a default setting of 24 slots (1.5 frames) -it will attempt to re-establish the link by responding to a GPO with a CT-HLD message. The BS will recognize the Cl associated with the CT-HLD as belonging to an MS that it thinks it is communicating with in SCT mode and will respond accordingly (probably a CT-HLD with the appropriate SCT parameters) .

2131If the MS loses a message during SCT mode, it will increment its 'leaky bucket' and attempt another transmission during the next assigned SCT slot-this is why the BS must preserve the SCT map for this MS until it has 1) re-established the link, 2) gotten solid confirmation that the MS is switching to a different SCT map, or 3) given up after Lost Link Recovery. If the leaky bucket overflows, it will implement normal Lost

2132Link Recovery, either initiating a handover, if appropriate, or searching for Specific Polls until its Lost Link Recovery timer expires.

2133No Slot Capacity to Exit SCT

2134If there are no available slots, then clearly the BS and MS cannot exit SCT mode. They will stay in SCT mode and continue signaling (non CT-HLD messages) until there are slots available. There is the risk that continuing to signal in SCT mode may cause timing problems for the higher level processes; if this occurs, the problems will be resolved by the higher level processes.

2135Operations and Management Of The Base Station To simplify BS management a degree of abstraction is used when addressing entities within a BS. This is achieved by addressing NM messages using the Managed Object Class and Managed Object Instance. There must be in the BSC an object model with a complete data link layer 424 description for each object instance in the BS. When a message has to be sent to an object instance this mapping is used to find the correct link.

2136The first connection is established from the BS site using a (semi-) permanently programmed default TEL All OAM&amp;P procedures are sent on this connection. A further connection is established on the same TEI for Notes signaling.

2137Object instances also have a network layer address. The instance number is used to address the object instance. Network layer address is used by the manager and agent to determine which object instance is being addressed. In this case the agent must have this instance number (semi-) permanently programmed.

2138For inter-operability, link configuration, default TEI assignment and instance numbering must be known by both manager and agent. This as well as supported functions are considered as Shared Management Knowledge.

2139SW Download Management Procedures

2140This section covers the download procedure for software by the Base Station from the Base Station Controller.

2141Load Data Initiate

2142This message is sent from the BSC to the BS to initiate the loading of a file. It indicates the number of segments for which a network layer acknowledgment is required (window size) . When receiving data the BS sends an ACK after this number of segments, except for the last batch.

2143Load Data Segment These multi-segment messages carry the files for the transfer initiated by the Load Data Initiate message. No other file transfer is allowed until the current transfer is finished. The ACK is for the number of segments specified in the Load Data Initiate message, except that when all the expected blocks have been received the ACK is sent regardless of the window size. If the timer for a time-out for the Layer 3 acknowledgment expires, the BSC sends a Load Data Abort message and the file transfer is aborted.

2144Meaning of Ack message: A window of Load data segment messages or a complete file has been received.

2145Load Data Abort

2146This message is used by either end if the file transfer can no longer be supported. This message will also be used by the BS if the received amount of data exceeds the expected amount.

2147Load Data End

2148This message is sent by the BSC to the BS. The BS sends an ACK when the file has been received in the BS. SW Activate Request

2149This message is sent by the BS when the resource presented by the object instance (BS manager or BS) has started up. The initialization of mentioned object instance is started with software activation, which may include software download continuing with attribute setting.

2150Activate SW

2151This message from the BSC to the BS activates the loaded software, indicating which file (or files) is to be activated. The acknowledgment of the Activate SW indicates if the software can be activated, or if it cannot (by use of a NACK) . The activation may include BS internal software distribution.

2152SW Activated Report

2153This message from the BS to the BSC is sent from the addressed object on the BS at a successful completion of the software distribution to and activation on all indicated destinations in the BS.

2154Air Interface Management Procedures

2155This section covers the Base Station Controller commands for setting O-Interface 510 for the Base Station.

2156Set BS Attributes

2157This message is sent to the BS manager object, providing BS attributes related to the air interface and attributes that are common for all TRXs.

2158Set TRX Attributes

2159This message is sent for every TRX instance providing all the necessary attributes relating to that TRX. This message also includes any information that is common to all channels of the TRX.

2160Test Management Procedures

2161This section covers the testings commands sent by the Base Station Controller to the Base Station. Perform Test

2162This message tells the BS to perform a test, if necessary to set a physical configuration for the BSC to carry out a test on the BS, or to perform a test using a particular configuration. Any measurements may be performed as specific tests. Duration for the test can be given, after which the test report may be autonomously sent if so requested.

2163Two tests are defined. 1. A radio loop test via the transceiver is used to test most of the equipment needed to provide service of one traffic channel. The loop starts and ends in the transceiver baseband parts and loops one traffic channel back inside the transceiver before the antenna. The baseband parts of the transceiver calculate the bit error rate to describe the quality of service that channel provides. This test can be used in conjunction with the previous test to discriminate the location of a possible hardware failure. 2. BS self test is used to activate BS internal self test procedures made to test equipment that provides the services of a logical object.

2164Test Report

2165This message is sent by the BS giving the result of a test ordered by the BSC and is sent autonomously as soon as the result is available. The Test Report shall also be sent after a specific request from the BSC, "Send Test Report". The Test Report indicates what was tested, the test type, and the result. No Ack or Nack is returned to the BS.

2166Send Test Report

2167This message is sent from the BSC asking for the result/report of a test which is not to be sent autonomously, or which is made continuously, in which case the present result of the test is required. The message includes identification of the test . Stop Test

2168This message is used by the BSC to stop a continuously recurring test at the BS, to reset a physical test configuration to the normal configuration, or to stop the test and to restore to the normal physical configuration. The message includes identification of the test being performed.

2169Performance Management Procedures

2170This section covers the performance management procedures by the Base Station.

2171Perform Measurement

2172This message tells the BS to perform a measurement. It indicates the type of measurement to be performed and the measurement reporting schedule (which corresponds to the measurement result 'granularity') . This procedure may be used for an already running measurement to modify the reporting schedule.

2173Measurement Report

2174This message is sent by the BS giving the results of a measurement ordered by the BSC. The reporting may be either scheduled or requested, which is indicated in the message. No Ack or Nack is returned to the BS.

2175Send Measurement Results

2176This procedure is used by the BSC to request a copy of the current results for a measurement it previously ordered. This procedure does not affect the measurement collection within the BS, nor does it affect the scheduled reporting of measurement results.

2177Stop Measurement

2178This procedure is used by the BSC to stop a measurement in the BS that it previously ordered. Any results not yet reported are lost. State Management and Event Report Procedures

2179This section covers the reports and information provided by the Base Station to the Base Station Controller.

2180Changed State Event Report

2181An unsolicited report is sent from the BS to the BSC whenever a change of operational state of a managed object (defined in this specification) or of the optional manufacturer dependent state occurs . The message is also sent when any site input changes its state.

2182A failure, causing change of operational state, shall generate two event reports, Change State Event Report and Failure Event Report. No Ack or Nack is returned to the BS.

2183Failure Event Report

2184An unsolicited report is sent from the BS to the BSC whenever failure events occur in the BS. Such failure events are: fault report, resulting from passing a threshold, but not constituting a failure. failure of a resource. There shall be a report for failure start and another for failure ceased. A failure causing change of operational state shall generate two event reports, Change State Event Report and Failure Event Report. No Ack or Nack is returned to the BS .

2185Stop Sending Event Reports

2186The inhibition of sending of event reports is used by the BSC to prevent a flood of event reports which are of no benefit to the BSC. One example of this occurs at a BS restart following a power failure. The operational capability of the BS hardware is unlikely to be different from what it was before the failure, and a flood of reports, each stating that a piece of hardware is operating, will delay the software download. Another example concerns the case of a frequently occurring transient fault. Restart Sending Event Reports

2187When the BS is back in normal operation or if it is of interest to check whether the BTS still generates a flood of Event Reports a Restart Sending Event Reports should be sent .

2188Change Administrative State

2189The Change Administrative State message is used by the BSC to change the administrative state for a managed object.

2190Change Administrative State Request

2191The request message is sent by the BS when there is a need to change the administrative state of a managed object at the BS site. This message can only be initiated as a result of a local MMI command.

2192Equipment Management Procedures

2193This section covers the equipment management commands sent by the Base Station Controller and their response.

2194Opstart

2195This message is sent by the BSC to tell the BS to attempt to operate the identified object putting it to an initial normal operational state (i.e., "enabled") . This message does not affect the object's administrative state if there exists a value explicitly assigned by the BSC. If there is yet no administrative state value explicitly set by the BSC (e.g., at an initialization time) , the object shall be presumed to be administratively locked by default. No BS function is responsible for testing the operability of the identified resource as a consequence of this message. Prior to this message being issued, all necessary physical and logical preparations (such as repair of equipment, software downloading, parameter setting, etc., as needed) are expected to have been completed. If the object is in fact not ready to be in an enabled state, the object will be in a fault condition as a consequence of this message, and the condition shall be handled by the object's usual fault handling function as the condition is detected. Reinitialize

2196This message is sent by the BSC to tell the BS to have specified resource of the indicated object start a re¬ initialization procedure.

2197Set Site Outputs

2198This message is sent by the BSC to tell the BS to set specified site outputs to the specified state.

2199Miscellaneous Procedures

2200This section outlines additional procedures requested by the Base Station Controller.

2201Get Attributes This message is used by the BSC to tell the BS to send attributes which have previously been set by the BS. It may be used as a check on accuracy and be incorporated into normal procedures, or may be used by the BSC to recover information which it has lost, in the absence of the OMC.

2202Set Alarm Threshold

2203This message is used by the BSC to tell the BS some threshold parameters related to fault thresholds.

2204Message Categories

2205This section defines the transport format and coding of the two Network. Management message categories sent over the NOTES OAM&amp;P interface. The various message categories may be sent in either direction. In each message, the message discriminator identifies the category and is transmitted first. In a message the octets are sent in the order shown in the description of. the messages. In an octet bit 1 is transmitted first.

2206In the following sub-sections M and 0 denote whether information elements are mandatory or optional. Formatted O&amp;M messages

2207The message format and coding of these messages is below:

INFORMATION ELEMENT M/O LENGTH CODING

2209Message Discriminator M 1 1 0 0 0 0 0 0 0

2210Placement Indicator M 1 Note 1

2211Sequence Number M 1 Note 2

2212Length Indicator M 1 Binary, Note 3

2213O&amp;M Data Field M V Note 4

2214Note 1: The meanings and codings of the Placement Indicator are: Only: This message is contained within one segment: 10000000 First: The first segment of a multi-segment message: 01000000 Middle: A middle segment of a multi-segment message: 00100000 Last: The last segment of a multi-segment message: 00010000 Note 2 : This is the sequence number of the segment in the message, modulo 256, starting with 00000000. Thus a single segment message is here coded 00000000, but this does not inhibit the use of this code in long multi-segment messages. Note 3 : The Length Indicator gives the length of the O&amp;M data field which is less than or equal to 255 octets. This length indicator should not be confused with attribute value length indicator described in Section 6.2.

2215Note 4 : Coding for O&amp;M Data field is found in Section and following subsections. Manufacturer-Defined O&amp;M messages

2216Messages of this format are not currently used, and are reserved for future used. INFORMATION ELEMENT M/O LENGTH CODING

22178 1

2218Message Discriminator M 1 0 0 0 1 0 0 0 0

2219Placement Indicator M 1 Note 1

2220Sequence Number M 1 Note 2

2221Length Indicator M 1 Binary, Note 3

2222Manld Length Indicator M 1 Binary, Note 4

2223Manuf. Identifier M V Note 5

2224Man-Defendant O&amp;M Data M V Proprietary Field

2225Note 1 : The meanings and codings of the Placement Indicator are : Only: This message is contained within one segment: 10000000 First: The first segment of a multi-segment message:

2226010000000 Middle: A middle segment of a multi-segment message: 00100000 Last: The last segment of a multi-segment message: 00010000 Note 2 : This is the sequence number of the segment in the message, modulo 256, starting with 00000000. Thus a single segment message is here coded 00000000, but this does not inhibit the use of this code in long multi-segment messages. Note 3 : The Length Indicator gives the length of the

2227Manufacturer-defined O&amp;M data field which is less than or equal to 255 octets. Note 4 : The Length Indicator gives the length of the

2228Manufacturer Identifier field which is less than or equal to 255 octets. Note 5: The Manufacturer Identifier is an octet string of maximally 255 octets.

2229MMI Transfer

2230The message formats for MMI transfer are defined here for future use, and are not currently used. INFORMATION ELEMENT M/O LENGTH CODING

22318 1

2232Message Discriminator M 1 0 1 0 0 0 0 0 0

2233Placement Indicator M 1 Note 1 of Sec. 5.1.1

2234Sequence Number M 1 Note 2 of Sec. 5.1.1

2235Length Indicator M 1 Binary, Note 1

2236MMI Data Field M V for future use

2237Note 1: The Length Indicator gives the length of the MMI data field, which is less than or equal to 255 octets.

2238Structure of Formatted O&amp;M Messages

2239This section provides details of all the messages. In every case when particular header octets provide no usable information at the receiver, they are coded all 1's.

2240The header fields of formatted O&amp;M messages are always mandatory. The attributes defined for a certain message supported by the BTS implementation are mandatory to be used if not stated otherwise in an explanatory note.

2241Message types are identified in the first octet of the formatted O&amp;M messages. Some messages are replied by a Response, an ACK or a NACK. These replies are distinguished by different codings of the message type (the first octet of formatted O&amp;M messages) .

2242ACK messages return all the attributes in the original message. NACK messages add two octets (one for an attribute identifier and one for a cause) at the end of the message.

2243None of the messages concerned requires all of the capacity available in a Layer 2 segment, so the NACK message will not need a second Layer 2 frame.

2244An ACK to a number of 'Load Data Segment's only consists of the header with the 'Load Data Segment Ack' message type.

2245All attributes overwrite those defined in an earlier message since start-up or the last restart. Optional attributes provide new information if they have not been defined in an earlier message. The message type 1 byte, object class 1 byte, and object instance 3 bytes are all included in each message header.

2246The Object Class information element shall be filled in with the correct information in accordance with this specification.

2247The Object Instance information element contains two useful fields :

2248TRX number that identifies the TRX in a multi-TRX BS.

2249Timeslot number that identifies the Channel within a particular TRX.

2250The FORMAT field describes the structure of each information element using T (Tag) , L (Length) and V (Value) coding. T is the attribute identifier. V is the actual information presented. L is indicated if the information element is of variable length and its prediction is not possible in the context . Length binary-represents in a two octet space the number of octets in the remaining part of information element .

2251SW Download Management Messages Load Data Initiate

2252The load data initiate message includes the header, a description of the software at least 3 bytes long, and a window size 2 bytes long. Load Data Segment

2253The load data segment message includes the header and the file data segment that is to be transferred which is at least 3 bytes long.

2254Load Data Abort The load data abort message includes the header and the abort message.

2255Load Data End

2256The load data end message includes the header and the description of the software which is the same as the description of the software in the load data initiate message. SW Activate Request

2257The software activate request message includes the header, the hardware configuration at least 3 bytes and the software configuration which is also at least 3 bytes.

2258Activate SW

2259The activate software message includes the header and the software description of at least 3 bytes. Software Descriptions may be repeated for multiple software activation. No software description entry implies all software for the object instance.

2260SW Activated Report

2261The software activated report message includes the header and the acknowledgment of activation.

2262Air Interface Management Messages Set BS Attributes

2263The set Base Station attributes message includes the header, BSC ID (3 bytes) , BS ID (3 bytes) , LAC (3 bytes) , MCC (3 bytes) , MNC (3 bytes) , BS capabilities (5 bytes) , system type (2 bytes) , service provider 2 bytes, BS TX Power Maximum (2 bytes, power control size (2 bytes) , RX mode (2 bytes) , TX mode (2 bytes) , and HO information (Desired Length) .

2264Set TRX Attributes

2265The set TRX attributes message includes the header, Radio Channel ID (2 bytes) , PN code (2 bytes) , MAX bandwidth (2 bytes) , and MIN bandwidth (2 bytes) .

2266Test Management Messages Perform Test

2267The perform test message includes the header, Test Number (2 bytes) , Autonomously Report request (2 bytes) , Test Duration (3 bytes) , and the physical configuration during testing (at least 2 bytes) . Use of Physical Configuration depends on the need on extra information in setting up specific test configurations. Test Report The test report message includes the header, the test number performed (2 bytes) , and test report information (at least 3 bytes) . The test report information may give a numerical result or an indication of the range into which the test report falls.

2268Send Test Report

2269The send test report message includes the header and test number (2 bytes) .

2270Stop Test The stop test message includes the header and the test number to be stopped (2 bytes) .

2271Perform Measurement

2272The perform measurement message includes the header, measurement type (1 byte) , and the reporting schedule (1 byte) .

2273Measurement Report The measurement report message includes the header, measurement type (1 byte) , reporting reason (1 byte) , and measurement results (at least 3 bytes) .

2274Send Measurement Results The send measurement results message includes the header and the measurement type (1 byte) .

2275Stop Measurement

2276The stop measurement message includes the header and the measurement type to be stopped (1 byte) .

2277State Management and Event Report Messages

2278Changed State Event Report The changed state event report message includes the header, operational state (2 bytes) , availability status (at least 3 bytes) , and the site input (at least 3 bytes) . Failure Event Report

2279The failure report event message includes the header, event type (2 bytes) , perceived severity (2 bytes) , probable cause (4 bytes) , the hardware description (at least 3 bytes) , the software description (at least 2 bytes) , and additional information (generally greater then 2 bytes) . Depending on the nature of the specific failure and the BS implementation, only the needed/supported attributes shall be sent. These fields shall be included to identify the specific associated equipment or software in case the addressed functional object alone is not sufficient to localize the failure.

2280Stop Sending Event Reports

2281The stop sending event reports message includes the header, operational state (2 bytes) , availability status (at least 3 bytes) , and the probable cause (4 bytes) . Stop Sending Event Reports concerning events with any of the parameter values in this attribute list. Depending on the type of event report that shall be stopped, one of the attributes shall be sent.

2282Restart Sending Event Reports

2283The restart sending event reports message includes the header, operational state (2 bytes) , the availability status (at least 3 bytes) , and the probable cause (4 bytes) . Restart sending Event Reports concerning events with any of the parameter values in this attribute list . Depending on the type of event report that shall be restarted, one of the attributes shall be sent.

2284Change Administrative State

2285The change administrative state message includes the header and the new administrative state (2 bytes) .

2286Change Administrative State Request The administrative state request message includes the header and the requested administrative state for the object (2 bytes) . Equipment Management Messages

2287Opstart

2288The opstart message includes the message header which signifies that operation is to begin.

2289Reinitialize

2290The reinitialize message includes the header and the hardware to be reinitialized (at least 3 bytes) . HW Descriptions may be repeated for multiple resources. If no HW Description is provided, all resource for the objects is implied. For a software reinitialization, Activate SW message shall be used.

2291Set Site Outputs The set site outputs message includes the header and the site outputs (at least 3 bytes) .

2292Get Attributes

2293The get attributes message includes the header and the list of required attributes (att least 3 bytes) .

2294Set Alarm Threshold

2295The set alarm threshold message includes the header, probable cause (4 bytes) , and additional required information.

2296Coding

2297This Section defines the coding of each field in the messages defined in earlier Sections.

2298The following conventions are assumed. The least significant bit is transmitted first, followed by bits 2, 3, 4, etc. In an element, octets are identified by number. Octet 1 is transmitted first, then octet 2, etc. Further:

2299When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.

2300For unpredictable variable length elements, a length indication coding method shall be used. Always the Tenth information indicates the number of element units (which is octets) following the length indicator.

2301All used values are indicated. Other values are reserved.

2302Message Type

2303The Message Type is coded with 1 octet.

2304The message types used are described above.

2305Object Class

2306An Object Class is coded with 1 octet. The values of the object class code are as defined below:

2307Object Class hexadecimal code

2308Base Station Manager 00

2309Base Station 01

2310Transceiver 02

2311Channel 03

2312•preserved for future use> < 04-FE>

NULL FF

2314Object Instance

2315The Object Instance is coded with 3 octets, addressing the specific object of the given object class as illustrated below:

NULL 1

2317Transceiver number 2

2318Timeslot number 3

2319These three octets are mandatory in the header of every message. The NULL byte is reserved for future use (in case of changes to information model) , and is coded NULL.

2320The Transceiver number distinguishes TRXs at a site under the Base Station. The Timeslot number distinguishes channels under the TRX. When the object class is BS Manager all the octets are

2321NULL, as there is only one BS manager. When the object class is BS all the octets are NULL, as there is only one BS. When the object class is TRX, octet 2 is a binary pre¬ sentation of the number of the addressed TRX Octet 3 is coded NULL. If the TRX number is NULL, it shall be understood to refer to all TRXs under the BS.

2322When the object class is Channel, octet 3 is a binary presentation of the number of the addressed Timeslot, and octet 2 is the number of the TRX above the addressed Channel. If the Timeslot number is NULL, it shall be understood as referring to all Channels under the TRX.

2323To avoid unnecessary complexity of BS implementation, it shall not be allowed to assign a NULL value for the TRX number in the case that the Channel object class is addressed (without this constraint, this could be understood as referring to a particular channel of all TRXs) . The value for NULL is <FF> in all the cases mentioned above in this Section.

2324Attributes and Parameters

2325The Attribute Identifier is coded with 1 octet. The number of parameters within an attribute I at least one. The length of the parameters within an attribute will vary.

2326The data structures of the attributes and parameters are described in the remaining part of this section in tabular forms with no formal text description of the individual subsections provided because of their self-explanatory nature Henceforth "Attribute Identifier" in this section means the identifier for an attribute or a parameter.

2327Additional Text

2328Attribute Identi .fier 1

2329Length 2-3

2330Additional Text 4

2331(cont. )

2332(cont . ) N

2333'Additional Text' is ASCII coded diagnostic or debug information that will not be interpreted by the system (or the operator) but may help engineers to more precisely identify failure causes. Administrative State

2334Attribute Identifier

2335Administrative State

2336Administrative State is coded as follows:

2337Locked 01

2338Unlocked 02

2339Shutting Down 03

2340NULL (Adm. State not supported) FF

2341Autonomously Report

2342Attribute Identifier

2343Autonomously Report

2344Autonomously Report

2345Autonomously Report 01 Not Autonomously Report 00

2346Availability Status

2347Attribute Identifier 1

2348Length 2-3

2349Availability Status 4

2350(cont. )

2351(cont. ) N

2352Availability Status may contain one or more octets. Each octet has a single status value, which is coded as follows:

2353In test 0

2354Failed 1 Power off 2

2355Off line 3

2356<not used> 4

2357Dependency 5

2358Degraded 6

2359Not installed 7 BS Capabilities

2360Attribute Identifier

2361Facility

2362(cont . )

2363(cont. )

2364(cont . )

2365^XBS capabilities' defines the services being offered by the S coded as bit-map of 32 bits.

2366BS Identity

2367Attribute Identifier

2368Base Station Identity

2369(cont. )

2370(cont

2371(cont. )

2372Base Station Identity <32 bits> where the low order bit is it 1 octet 2 and the high order bit is bit 8 octet 5.

2373BS maximum TX power

2374Attribute Identifier

2375BS max TX power

2376BS max TX power at antenna input <dBm or dBw>

2377BSC Identity

2378Attribute Identifier

2379BSC Identity

2380(cont. )

2381BSC identity <16 bits> where the low order bit is bit 1 of octet 2 and the high order bit is bit 8 of octet 3. Event Type

2382Attribute Identifier

2383Event Type

2384Event Type communication failure 00 quality of service failure 01 processing failure 02 equipment failure 03 environment failure 04 _<reserved for future use> <05-FF>

2385File Data

2386Attribute Identifier 1

2387Length 2-3

2388File Data 4

2389(cont. )

2390(cont. ) N

2391The coding of 'File data' is not defined in this specification.

2392File Id

2393Attribute Identifier 1

2394Length 2-3

2395File Id 4

2396(cont. )

2397(cont N

2398File Version

2399Attribute Ident. Lfier 1

2400Length 2-3

2401File Versi .on 4

2402(cont . )

2403(cont . ) N HW Conf iguration

2404Attribute Identifier 1

2405Length 2-3

2406HW Description 1 4

2407HW Description n N

2408HW Configuration contains a list of HW Descriptions related o a managed object.

2409HW Description

2410Attribute Identifier 1

2411Equipment Id Length 2-3

2412Equipment Id

2413(cont . )

2414Equipment Type Length

2415Equipment Type

2416(cont . )

2417Equipment Version Length

2418Equipment Version

2419(cont. )

2420Location Length

2421Location

2422(cont. )

2423All fields are variable length ASCII character strings, The coding of these fields will not be defined in this specification.

LAC

2425Attribute Identifier

2426Location Area Code List of Required Attributes

2427Attribute Ident l-fier 1

2428Length 2-3

2429Attribute Id. 4

2430(cont . )

2431(cont. ) N

2432Each Attribute Id is one octet

2433Maximum Bandwidth

2434Attribute Identifier

2435Multiple Timeslot Limit

2436'Multiple timeslot Limit' indicates the maximum number of TDMA timeslots (of the same frame) that can be assigned to a bearer channel (coded <1..16>) .

2437Maximum MS power reduction

2438Attribute Identifier

2439Max MS power reduction

MCC

2441Attribute Identifier

2442Mobile Colour Code

2443Measurement Results

2444Attribute Identifier 1

2445Length 2-3

2446Measurement results 4

2447(cont ,

2448(cont . ) N

2449Measurement results &lt;binary coded decimal value with meaning determined by measurement type . Measurement Type

2450Attribute Identifier

2451Measurement Type

MNC

2453Attribute Identifier

2454Mobile Network Code

2455Minimum Bandwidth

2456Attribute Identifier

2457Sub-Multiple Timeslot Limit

2458'Sub-Multiple Timeslot Limit' indicates the maximum separation (between frames) of TDMA timeslots that can be assigned to a bearer channel (coded <1..25>) .

2459Nack Causes

2460Attribute Identifier

2461NACK Cause

2462Nack Causes

2463General Nack Causes :

2464Incorrect message structure 01

2465Invalid message type value 02

2466Invalid Object class value 03

2467Object class not supported 04

2468Object Instance unknown 05

2469Invalid attribute identifier value 06

2470Attribute identifier not supported 07

2471Parameter value outside permitted range 08

2472Inconsistency in attribute list 09

2473Specified implementation not supported OA

2474Message cannot be performed OB

2475<reserved> <OC-l F>

2476Specific Nack Causes:

2477Resource not implemented 20 Resource not available 21 Frequency not available 22

2478Test not supported 23

2479Capacity restrictions 24 Physical configuration cannot be performed 25

2480Test not initiated 26 Physical configuration cannot be restored 27

2481No such test 28

2482Test cannot be stopped 29 Message inconsistent with physical config. 2A

2483Complete file not received 2B

2484File not available at destination 2C

2485File cannot be activated 20

2486Request not granted 2E

2487Wait 2F

2488Measurement not supported 30

2489Measurement not initiated 31

2490No such measurement 32

2491Measurement cannot be stopped 33

2492<reserved> <34-FE>

NULL FF

2494Conflicting or incomplete data in the attribute list which prevents the BS from performing the message (for 08) . This Nack cause applies when the message is valid and is supported by the BS, but cannot be performed correctly for reasons not covered by other general or special Nack causes (09) . Data in attribute list is valid, but beyond the capabilities of the particular BS implementation (30) .

2495NOTES Channel

2496Attribute Identifier

2497BS Port Number

2498Timeslot Number

2499Subslot Number

2500BS Port Number <0-FF> Timeslot Number

2501Time slot in transmission link < 0 - lF> Subslot Number a (bits 1,2) 00 b (bits 3,4) 01 c (bits 5,6) 02 d (bits 7,8) 03

250264 kbps signaling FF

2503Operational State

2504Attribute Identifier

2505Operational State

2506Operational State

2507Disabled 01

2508Enabled 02

2509These states are in accordance with ISO/CCITT values (X.721) <reserved for future use> <03-FE>

2510NULL (Operate. State not supported) FF

2511Perceived Severity

2512Attribute Identifier

2513Severity Value

2514Severity Value failure ceased 00 critical failure 01 major failure 02 minor failure 03 warning level failure 04 indeterminate failure 05 <reserved> <06-3F>

2515PN Code

2516Attribute Identifier

2517PN code (0..7; Power control step size

2518Attribute Identifier

2519Power control step size

2520Probable Cause

2521Attribute Identifier

2522Probable Cause Type

2523Probable Cause Value

2524Probable Cause Value (cont . )

2525Probable Cause Type

2526ISO/CCITT values (X.721) 01

2527GSM specific values 02

2528Omnipoint specific values 03

2529_<reserved for future use> <04-FF> Probable Cause Value

2530When Probable Cause Type is 01, 02 or 03 the last numeric value of the object identifier value specified in ASN.l syntax coding is used.

2531Physical Config

2532Attribute Identifier 1

2533Length 2

2534Required Test Config 4

2535(cont. )

2536(cont. ) N

2537Radio chanrie! ID

2538Attribute Identifier

2539Radio channel ID (hex coded)

2540Reporting F .eason

2541Attribute Identifier i

2542Reporting Reason 2 Reporting Reason

2543Scheduled Reporting 0 Requested reporting 1

2544Reporting Schedule

2545Attribute Identifier

2546Reporting Schedule

2547Reporting Schedule <5,15,30,60> minutes

2548RX Mode

2549Attribute Identifier

2550RX Mode (interference/noise limited)

2551Servic :e Provider

2552Attribute Identifier 1

2553Service Provider 2

2554(cont. ) 3

2555'Service Provider' is coded on 32 bits with Low order bit being 1 octet 2 and high order bit being bit 8 octet 3.

2556Site Inputs

2557If Site Inputs are requested from BS Manager with message Get Attributes, all inputs are listed.

2558Attribute Identifier 1

2559Length 2-3

2560Site Input 4

2561(cont. )

2562(cont N

2563Each octet from 4 to N controls one Site input. Each of these octets contain the input number and the status of the input and they are coded as follows: State . Input number

2564J_

2565State is a binary presentation of the input state, 0 or 1. Input number is a binary presentation of input number, {the use of Site Inputs is tbd)

2566Site Outputs

2567If Site Outputs are requested from BS Manager with message Get Attributes, all outputs are listed. Coding of this information element is the same as in Site Inputs.

2568Attribute Identifier 1

2569Length 2-3

2570Site Output 4

2571(cont. )

2572(cont. ) N

2573SW Configuration

2574Attribute Identifier 1

2575Length 2-3

2576SW Description 1 4

2577SW Description n N

2578SW Conf. contains a list of SW Descriptions related to the managed object.

2579SW Description

2580Attribute Identifier 1

2581File Id 2

2582File Version N System Type

2583Attribute Identifier

2584System Type

2585System type

25860 DCS1900 cause codes

25871 Bellcore Generic C Cause Codes 2-255 Reserved

TEI

2589Attribute Identifier

TEI

2591TEI <0..63>

2592Test Duration

2593Attribute Identifier 1

2594Test Duration 2-3

2595Test Duration <01-FFFF>

2596Test Duration is a binary presentation of seconds indicating the time the test should last.

2597Test No

2598Attribute Identifier

2599Test Number

2600Test Number

2601<not used> 00

2602Radio loop test via transceiver 01

2603BS self test 02 Test Report Info

2604Attribute Identifier 1

2605Length 2 - 3

2606Test Result Info 4

2607(cont . )

2608(cont . ) N

2609TX Mode

2610Attribute Identifier

2611TX Mode (Linear/non-linear)

2612Window Size

2613Attribute Identifier

2614Window Size

2615Window Size is a binary presentation of the number of layer 3 Load Data Segments to be sent before a layer 3 acknowledgment . Value 0 is not used.

2616PCS2000 Privacy &amp; Authentication Requirements

2617This section sets forth the general requirements for PCS Privacy and Authentication, (P &amp; A) for the PCS2000 Air Interface system to the DCS-1900 and, alternatively, to the Bellcore Generic C/ISDN based network architectures. The need for privacy and authentication is based on the use of radio transmission for access to communication services. The radio transmission access or air interface is particularly sensitive to the use of PCS services by unauthorized users and eavesdropping on voice and data information which is exchanged over the air interface. Since wireless access intrinsically does not provide for the same level of protection to their service operators and users as the traditional public and private wireline telecommunication networks, additional security features are required to protect access to the PCS services offered by service providers the privacy of the user's voice, data, or other information Common Requirements UIM - AC Authentication

2618The permanent data required for authenticating the user shall be stored in the Authentication Center (AC) and in the User Identity Module (UIM) .

2619Fraud Protection

2620The authentication process shall protect against attempts to obtain service illegally. This includes interception of call information, take-over attacks and "cloning". Protection shall be upgradeable for the life of the system.

2621Forward Compatibility PCS2000 P&amp;A functionality shall be both upgradeable and forward compatible for the life of the system.

2622Protection of Secret Data

2623No user or service provider secrets, either permanent or temporary, shall be allowed to pass unencrypted over the radio channel.

2624Radio Channel Protection From External Manipulation PCS2000 radio channels shall be protected from external malicious signaling manipulation.

2625User Simplicity &amp; Transparency

2626From the user prospective, the PCS2000 P&amp;A processes shall be virtually transparent . The user shall incur a minimum of inconvenience and the wireless calling process shall be no more complicated than the conventional wireline process.

2627Low Complexity

2628PCS2000 P&amp;A shall add minimum complexity to the MS and to the network.

2629Registration &amp; Call Set-up Time Impacts

2630The PCS2000 P&amp;A process shall add a minimum amount of time to the call set-up time. Error Tolerance

2631The PCS2000 P&amp;A processes shall be robust to noise and interference .

2632Two Way Authentication

2633In addition to authenticating the user to the provider's network, the service provider's network shall be optionally authenticatable to the MS.

2634Business-Friendly

2635The PCS2000 P&amp;A processes shall be amenable to an unregulated competitive business environment. A minimum amount of trust and interworking arrangements are desirable in order to let service providers serve each others roamers with a minimum of concern and perceived monetary risk an a maximum degree of mutual advantage.

2636GSM Based Privacy and Authentication Introduction All security functions must be implemented with minimum assumptions about the cryptological algorithms that are used, and it must be possible to change these algorithms during the system life time. Any change in these algorithms must not change the format of the messages exchanged via the interfaces of the system. The system must be prepared for parallel operation of more than one algorithm during a transitional period.

2637The security procedures must includes mechanisms to enable recovery in event of signaling failures. These recovery procedures must be designed in such a way that they cannot be used to breach the security of the system.

2638Security Features

2639The security features described in the following provide a level of protection at the radiopath that is at least as good as the level of protection provided in the fixed networks. The following security features are considered: user identity (IMSI) confidentiality; user identity (IMSI) authentication; user data confidentiality on physical connections; signaling information element confidentiality. The implementation of these four security features is mandatory on both the fixed infrastructure side and the MS side. This means that all PCS2000 networks and all MSs shall be able to support every security feature. Use of these four security features is at the discretion of the operator for its own subscribers while on the home network. For roaming subscribers, use of these four security features is mandatory unless otherwise agreed by all the affected PCN operators.

2640User identity confidentiality The user identity confidentiality feature is the property that the IMSI is not made available or disclosed to unauthorized individuals, entities or processes.

2641This feature provides for the privacy of the identities of the users who are using PCS resources (e.g. a traffic channel or any signaling means) . It allows for the improvement of all other security features (e.g. user data confidentiality) and provides for the protection against tracing the location of a mobile user by listening to the signaling exchanges on the radio path.

2642This feature necessitates the confidentiality of the user identity (IMSI) when it is transferred in signaling messages together with specific measures to preclude the possibility to derive it indirectly from listening to specific information, such as addresses, at the radiopath.

2643The means used to identify a mobile user on the radiopath consists in a local number called TMSI (Temporary Mobile Subscriber Identity) .

2644When used, the user identity confidentiality feature shall apply for all signaling sequences on the radiopath. However, in the case of location register failure, or in case the MS has no TMSJ available, open identification is allowed on the radio path.

2645User identity authentication International Mobile Subscriber Identity (IMSI) authentication is the corroboration by the land-based part of 201 the system that the user identity (IMSI or TMSI) , transferred by the mobile user within the identification procedure at the radiopath, is the one claimed.

2646The purpose of this security feature is to protect the network against unauthorized use. It also provides for the protection of the PCS users by denying the possibility for intruders to impersonate authorized users.

2647The authentication of the PCS user identity may be triggered by the network when the user applies for: • a change of a subscriber-related information element in the

2648VLR or HLR (including some or all of location updating involving change of VLR, registration or erasure of a supplementary service) , or

2649• an access to a service (including some or all of: set-up of mobile originating or terminated calls, activation or deactivation of a supplementary service) , or

2650• first network access after restart of MSC/VLR,

2651• or in the event of cipher key sequence number mismatch. Physical security means must be provided to preclude the possibility to obtain sufficient information to impersonate or duplicate a user of PCS, in particular by deriving sensitive information from the mobile station equipment.

2652When the user identity authentication procedure fails on an access request to the PCS, and this failure is not due to network malfunction, the access to the PCS shall be denied to the requesting party.

2653Authentication during a malfunction of the network:

2654• Calls are permitted (including continuation and hand-over) when an MS is registered and has been successfully authenticated, whether active or not active on a call.

2655• Calls are permitted when an MS has already been registered (and therefore been already authenticated) and can not be successfully reauthenticated due to the network malfunction (e.g. the Home PCS was not able to provide authentication pairs RAND, SRES) .

2656• Calls are not permitted when an MS attempts to register and can not be successfully authenticated due to the network malfunction. • A new registration needs to be performed when the MS is not registered, or ceases to be registered, and the preceding cases apply.

2657User data confidentiality on physical connections (voice and non-voice)

2658The user data confidentiality feature on physical connections is the property that the user information exchanged on traffic channels is not made available or disclosed to unauthorized individuals, entities or processes.

2659The purpose of this feature is to ensure the privacy of the user information on traffic channels.

2660Encryption will normally be applied to all voice and non- voice communications. Although a standard algorithm will normally be employed, it is permissible for the mobile station and/or PCS infrastructure to support more than one algorithm. The infrastructure is responsible for deciding which algorithm to use (including the possibility not to use encryption, in which case confidentiality is not supported) .

2661When necessary, the MS shall signal to the network indicating which of up to seven encryption algorithm, plus one transparent algorithm, it supports. (Note: The effect of the "transparent algorithm" being selected is the same as not being encrypted.) The serving network then selects one of these that it can support (based on an order of priority preset in the network) , and signals this to the MS. The selected algorithm is then used by the MS and by the network.

2662Signaling information element confidentiality