OpenBTS is a system that is specifically designed for use in under-developed areas: as the equipment is cheap and easy to transport. OpenBTS is softwa...
this guide describe in detail how to install openbts.Full description
Full description
Sample complaint for support and damages
Full description
Thinking as far as claims and issuers is an effective reflection that backs better approaches for securing your application. Claims have an understanding with the issuer and allow the claims of the user to be accepted only if the claims are issued by
Adding ASA Firewall Image File to GNS3
Advanced Encryption Standard AES algorithm is one of the most common and widely used symmetric block cipher algorithm. This algorithm has its own particular structure to encrypt and decrypt sensitive data and is applied in hardware and software, all
Acknowledgement First and foremost we would like to thank Allah for giving us insight and discernment to choose this project; we would also like to thank Allah for driving to complete the project with great personal satisfaction. Without Allah, none of this would have been possible. . We would like to thank Dr. Karim Gomaa, our project adviser for the assistance and encouragement to pursue to this study. We have been amazingly fortunate to have an advisor who gave us the freedom to explore on our own and at the same time guide us to recover when our steps failed. Most importantly, we would like to thank our families for their love and support. Our families have been a constant source of love, concern and support even when the times were stressful. This work would not have been possible without the support of the National Telecommunications Regulatory Authority (NTRA) and the Bibliotheca Alexandrina's Planetarium Science Center.
Preface This book is the result of our work in the 5th year at the Department of Communication and Electronics at the Faculty of Engineering, Alexandria University – Egypt. The motivation and aim for this book was originally explain briefly what OpenBTS is and show our work in securing it. Hopefully, this book will be informative and useful as a starting point for people wanting to learn more about the Authentication and Encryption aspects of GSM, and specifically, OpenBTS.
Introduction and motivation A connection between two people – a caller and the other person – is the basic service of all telephone networks. Mobile phones connected to the GSM cellular network are used on a daily basis by hundreds of millions of users worldwide; GSM provide connections over a radio links. Traditional GSM equipment is not designed for use in under-developed & developing nations: it is too expensive both to install and run for the number of users reached. Even if there GSM network coverage, after any call – connection – is terminated, the calling end is charged for the service used and the cost would be too expensive for the people to afford. OpenBTS is a system that is specifically designed for use in under-developed areas: as the equipment is cheap and easy to transport. OpenBTS is software based therefore it is simple to assemble and no complex/expensive hardware is needed, this is why OpenBTS may be considered as a lowcost GSM implementation. However, ciphering and authentication algorithms were not implemented in OpenBTS and it is highly important that reasonable technological security measures are taken to ensure the privacy of user‘s phone calls and text messages (and data), as well to prevent unauthorized use of the service. We wrote this book to mention the facts of how we implemented the appropriate security measures. We included chapters explaining the GSM Network Basics, Authentication and Encryption Basics and OpenBTS codes used. We also included all of the challenges that we faced while working on the project and the future work that may be done to improve it.
Table of Contents 1.
2.
Chapter 1: About GSM 1.1. GSM History 1.2. GSM Architecture 1.2.1. Mobile Station 1.2.2. Base-Station Subsystem 1.2.3. Network and Switching Subsystem 1.1. OSI Model 1.1.1. Physical Layer 1.1.2. Data Link Layer 1.1.3. Network Layer 1.1.4. Transport Layer 1.1.5. Session Layer 1.1.6. Presentation layer 1.1.7. Application Layer 1.1.8. Protocol Stacks 1.2. GSM Air Interface 1.2.1. Radio Spectrum a scarce resource 1.2.2. Multiple Access Scheme 1.2.3. TDMA Frame Structure 1.2.4. What is a burst? 1.2.5. Timing Advance and Power Control 1.3. GSM Air Interface Protocols 1.4. GSM Control Channels 1.4.1. Air Interface – Layer 1 1.4.2. Air Interface – Layer 2 1.4.2.1. What is LAPDm? 1.4.2.2. Different Modes of Operation 1.4.2.3. Data Link Connection Identifiers (DLC) 1.4.2.4. Frame Format Peer-to-Peer Communications 1.4.3. Air Interface – Layer 3 1.4.3.1. Radio Resource Management 1.4.3.2. Mobility Management 1.4.3.3. Layer 3 – Frame Structure 1.4.4. Mobile Originating Call 1.4.5. Mobile Terminating Call 1.4.6. Location Update 1.4.7. Call Clearing About OpenBTS 2.1. Introduction
2.2. What‘s OpenBTS? 2.3. Main Components and their functions 2.4. Clock Modification 2.5. Installation of OpenBTS on Linux (Ubuntu) 2.5.1. GNU Radio Installation 2.5.2. OpenBTS Installation 2.5.3. Adding User Permissions to work with the USRP 2.5.4. Testing the USRP 2.6. Finding an Unused Frequency Band 2.7. Configure OpenBTS 2.8. Installing & Configuring smqueue 2.9. Asterisk Configuration 2.10. Software Architecture of OpenBTS 2.11. Using OpenBTS 2.12. Community Support Mobile Network Security 3.1. Importance of Security in mobile networks 3.2. Security in OpenBTS 3.3. Cryptography 3.4. GSM Security Mechanism 3.5. Ciphering 3.5.1. Stream Ciphers 3.6. GSM Encryption Algorithms 3.6.1. Frame Number 3.6.2. Overview 3.6.3. A3 - Authentication Algorithm 3.6.4. A8 - Cipher Key Generating Algorithm 3.6.5. Comp 128 3.6.6. A5 – Ciphering Algorithm 3.7. Summary: Authentication and Encryption Code Implementation of Encryption 4.1. Authentication 4.2. User data and Signaling Protection 4.3. Individual Subscriber Authentication Key (Ki) 4.3.1. Ki Code Implementation 4.4. Random Challenge (RAND) 4.4.1. Challenges introduced in this scope 4.5. A3A8 Algorithm 4.5.1. Functionality 4.5.2. A3A8 Implementation 4.6. Frame Number (FN)
4.6.1. Our Modifications 4.7. A5/1 Algorithm 4.7.1. Functionality 4.7.2. A5/1 Implementation 4.8. XORing Stage – Conversion from plain text to cipher text 4.8.1. Forward Error Correction and Radio Modem in L1 4.8.2. Normal Burst 4.8.3. SDCCH Channel Mapping 4.8.4. The Ciphering Process 4.8.5. Ciphering/Deciphering Code Parts 4.9. XORing in Details with Code implementations Authentication and Ciphering Messages 5.1. Authentication 5.1.1. Where is authentication applied? 5.1.2. Authentication during network malfunction 5.2. Ciphering in GSM 5.2.1. Ciphering mode setting 5.3. Authentication and Ciphering Implementations 5.3.1. Important Definitions 5.3.2. Reference of Functions 5.3.3. Information Elements 5.3.3.1. Preference requirements of information elements 5.3.3.2. Information Element Formats 5.3.3.3. Common Information Elements 5.3.4. Authentication Messages and Codes 5.3.4.1. Authentication Request 5.3.4.2. Authentication Response 5.3.4.3. Authentication Reject 5.3.5. Ciphering Messages and Codes 5.3.5.1. Cipher Mode Command 5.3.5.2. Cipher Mode Complete 5.3.6. Places of Authentication and Ciphering Implementations 5.3.6.1. Location Updating 5.3.6.2. Mobile Originating Call Establishment 5.3.6.3. Mobile Terminating Call Establishment 5.3.7. Authentication and Ciphering Procedures 5.3.7.1. The Purpose 5.3.7.2. Definitions 5.3.7.3. Reference of Functions 5.3.7.4. Codes 5.3.7.4.1. Authentication Procedure
Challenges 6.1. Attacking A5/1 6.1.1. History 6.1.2. Hellman‘s Time-Memory trade-off 6.1.3. A Cryptanalytic Time/Memory/Data Trade-off for Stream Ciphers 6.1.4. Clocking Back A5/1 6.1.5. Our Contribution 6.2. Lack of Information 6.2.1. Extracting the Ki from the SIM 6.2.2. Encrypted Frame 6.2.3. Comp128 and A5/1 Algorithms 6.3. Error in the GSM Standards Future Work 7.1. Flaws of the A3/A8 and A5/1 Security System in OpenBTS: 7.1.1. Flaws in A5/1 7.1.2. A5/2 7.1.3. A5/3 7.1.4. Conclusion 7.2. Flaws due to errors in the OpenBTS codes (fix me‘s) 7.2.1. Ciphering Key Sequence Number (CKSN) 7.2.2. RAND 7.2.3. Timers
Chapter 1: About GSM 1.1 GSM history At the beginning of the 1980s it was realized that the European countries were using many different, incompatible mobile phone systems, these systems are related to as 1G (first generation) systems. With the passage of time, the need for telecommunication services was remarkably increased. Due to this, CEPT (the Conference of European Posts and Telegraphs) founded a group to specify a common mobile system for the Western Europe. This group was named ―Groupe Spécial Mobile‖. Originally, the acronym GSM stood for Groupe Spécial Mobile, and the system name GSM arose. This abbreviation has since been interpreted in other ways, but the most common expression nowadays s Global System for Mobile communications. GSM is a 2G (second generation) system, the way the system is implemented up until the year 2001. During the time the GSM system was being specified, national telecommunication markets we deregulated. Requirements for openness and competition were built into the specifications as follows:
There should be several network operators in each Country, this would lead to competition in service provisions and it would ensure the rapid expansion of the GSM system. The GSM system must be an open system, meaning that it should contain welldefined interfaces between different system parts. GSM networks must be built without causing any major changes to the existing Public Switched Telephone Network (PSTN)
Other objectives:
The system must maintain a good speech quality The system must use radio frequencies as efficiently as possible The system must have adequate capacity The system must maintain good security for both the subscriber and the transmitted information
Mobile services based on GSM technology were first launched in Finland in 1991. Today, more than 690 mobile networks provide GSM services across 213 countries and GSM represents 82.4% of all global mobile connections. According to GSM World, there are now more than 2 billion GSM mobile phone users worldwide. GSM uses a variation of time division multiple access (TDMA). GSM digitizes and compresses data, then sends it down a channel with two other streams of user data, each in its own time slot. It operates at either the 900 MHz or 1800 MHz frequency band.
Introduction to GSM
Since many GSM network operators have roaming agreements with foreign operators, users can often continue to use their mobile phones when they travel to other countries.
1.2 GSM architecture A GSM network is made up of multiple components and interfaces that facilitate sending and receiving of signaling and traffic messages. The GSM architecture is made up of a collection of transceivers, controllers, switches, routers, and registers. The GSM network architecture as defined in the GSM specifications can be grouped into three main areas: Mobile station (MS) Base-station subsystem (BSS) Network and Switching Subsystem (NSS)
Figure 1.1: GSM architecture
2
3
OpenBTS
1.2.1 Mobile Station (MS): The MS (Mobile Station) is a combination of terminal equipment and subscriber data. The terminal equipment is the mobile equipment (ME) and the subscriber data is stored on the Subscriber Identity Module (SIM). Therefore, MS = ME + SIM Figure 1.2: Mobile Station Mobile Equipment (ME): This refers to the physical phone itself. The hardware itself contains the main elements of the mobile phone including the display, case, battery, and the electronics used to generate the signal, and process the data receiver and to be transmitted. Each phone is uniquely identified by the International Mobile Equipment Identity (IMEI) number. This is installed in the phone at manufacture and "cannot" be changed. The IMEI can usually be found by removing the battery of the phone and reading the panel in the battery well. It is accessed by the network during registration to check whether the equipment has been reported as stolen. Subscriber Identity Module (SIM) – The SIM is a small smart card that is inserted into the phone it contains the identification numbers of the user and a list of available networks. The SIM card also contains tools needed for authentication and Ciphering. The SIM carries information specific to the subscriber, such as IMSI, TMSI, Ki (used for encryption), Service Provider Name (SPN), and Local Area Identity(LAI). The SIM can also store phone numbers (storage size depends on the type of SIM used), the Kc (used for encryption), phone books, and data for other applications. A SIM card can be removed from one phone, inserted into another GSM capable phone and the subscriber will get the same service as always.
Introduction to GSM
1.2.2 Base Station Subsystem (BSS): The BSS is the link between the MS‘s of a defined area and the Network Switching System (NSS). The BSS consists of: 1. A minimum of one BTS (Base Transceiver Station) 2. One BSC (Base Station Controller) 3. One TRAU (Transcoding Rate and Adaption Unit)
Figure 1.3: Base Station System Base Transceiver Station (BTS): The BTS is the Mobile Station's access point to the network it handles the radio interface to the mobile station. The BTS is the radio equipment that corresponds to the transceivers and antennas used to provide the service each cell in the network. The interface between the MS and the BTS is known as the Um Interface or the Air Interface. Figure 1.4: Base Transceiver Station
4
5
OpenBTS
One BTS usually covers a single 120 degree sector of an area. So that a tower that has 3 BTSs will cover all 360 degrees around the tower. However, depending on geography and user demand of an area, a cell may be divided up into one or two sectors, or a cell may be serviced by several BTSs with redundant sector coverage.
120 ° Sector
Figure 1.5: 3 BTS for one tower A BTS is usually placed in the center of a cell. Its transmitting power defines the size of a cell. Each BTS serves a single cell. BTS‘s also includes the following functions: Encoding, encrypting, multiplexing (TDMA), modulating (and Demodulation), and feeding the RF signals to the antenna. Transcoding and rate adaptation Time and frequency synchronizing Voice through full- or half-rate services Decoding, decrypting, and equalizing received signals Random access detection Timing advances Uplink channel measurements In a large urban area, there will potentially be a large number of BTSs deployed. The requirements for a BTS are reliability, portability, and minimum cost. A BTS will have between 1 and 16 Transceivers (TRX), depending on the geography and user demand of an area. Each TRX represents one ARFCN. A group of BTSs are controlled by a BSC.
Introduction to GSM
Base Station Controller (BSC):
The BSC forms the next stage back into the GSM network. It controls a group of BTSs. It manages the radio resources for one or more BTSs. It communicates with the BTSs over what is termed the Abis interface.
The BSC assigns and releases frequencies and time slots for the MS. The BSC also handles intercell handover. It controls the power transmission of the BSS and MS in its area. The function of the BSC is to allocate the necessary time slots between the BTS and the MSC. It is a switching device that handles the radio resources. Additional functions include: Control of frequency hopping Performing traffic concentration to reduce the number of lines from the MSC Providing an interface to the Operations and Maintenance Center for the BSS Reallocation of frequencies among BTSs Time and frequency synchronization Power management Time-delay measurements of received signals from the MS Transcoder and Adaptation Unit (TRAU): The Transcoder is the equipment in which coding and decoding is carried out as well as rate adaptation in case of data. Although the specifications consider the TRAU as a subpart of the BTS, it can be sited away from the BTS (at MSC), and even between the BSC and the MSC. In the air interface (between the MS and BTS), the media carrying the traffic is a radio frequency. To enable an efficient transmission of digital speech information over the air interface, the igital speech signal is compressed. We must however also be able to communicate with and through the fixed network, where the speech compression format is different. Somewhere between the BTS and the fixed network, we therefore have to convert from one speech compression format to another, and this is where the Transcoder comes in.
6
7
OpenBTS
For transmission over the air interface, the speech signal is compressed by the MS to 13 Kbits/s full Rate or 5.6 Kbits/s half Rate. However, the standard bit rate for speech in the PSTN is 64 Kbits/s. The TRAU adapts the 64 Kbps from the MSC to the comparatively low transmission rate of the radio interface. It is able to compress speech from 64 Kbps to 16 Kbps, in the case of a full rate channel and to 8 Kbps in the case of a half rate channel. The following figure shows the possible locations where the TRAU could be inserted:
Figure 1.6: The possible locations where the TRAU could be inserted
Introduction to GSM
1.2.3 Network and Switching Subsystem (NSS): The GSM network subsystem contains a variety of different elements, and is often termed the core network. It provides the main control and interfacing for the whole mobile network. The major elements within the core network and the interfaces used between them are as follows:
Figure 1.7: Network and Switching Subsystem The NSS as we said is the core of every mobile network. As we already discussed before the BSS provides the radio link between the network and the MS, however the NSS is responsible for the control and database functions required to set up a call using one or more features: encryption, authentication and roaming.
8
9
OpenBTS
Mobile Switching services Centre (MSC):
Figure 1.8: Mobile Switching Services The main part of the NSS is the Mobile Switching Center (MSC), as it performs the switching of calls between the mobile and other fixed or mobile network users. It acts like a normal switching node of the PSTN or ISDN, and in addition provides all the functionality needed to handle a mobile subscriber, such as registration, authentication, location updating, handovers, and call routing to a roaming subscriber. It also provides an interface to the PSTN so that calls can be routed from the mobile network to a phone connected to a landline. Interfaces to other MSCs are provided to enable calls to be made to mobiles on different networks. The interface between the BSC and the MSC is known as the A Interface
The interface between two Mobile Switching Centers (MSC) is called the E Interface
Introduction to GSM
Gateway Mobile Switching Centre (GMSC):
Figure 1.9: Gateway Mobile Switching Center The GMSC is the point in the PLMN where calls to mobile subscribers enter the GSM network. Therefore each ME terminating call must be routed via a GMSC in the home PLMN of the called MS. The GMSC contains signaling functions for retrieving information from the concerned HLR, which tells how to proceed with call set-up. Depending on the interrogation result, the call is either re-routed by GMSC to the MSC where the mobile subscriber is located or forwarded according to the forward-to number.
Figure 1.10: Connections between Two Networks
10
11
OpenBTS
Home Location Register (HLR): The HLR is a database used for storage and management of subscriptions. It contains all the administrative information about each subscriber including their current location. The administrative information includes permanent data about subscribers, including a subscriber's service profile, and activity status. When an individual buys a subscription in the form of SIM then all the information about this subscription is registered in the HLR of that operator. In this way, the GSM network is able to route calls to the relevant base station for the MS. When a user switches on their phone, the phone registers with the network and from this it is possible to determine which BTS it communicates with so that incoming calls can be routed appropriately. Even when the phone is not active (but switched on) it re-registers periodically to ensure that the network (HLR) is aware of its latest position. There is one HLR per network, although it may be distributed across various subcenters to for operational reasons. Within the HLR, subscriber specific parameters are maintained, such as the Ki, wish is part of the security handling system and is never transmitted on any interface, it is only known to the HLR and SIM.
Each subscriber is assigned to one specific HLR, which acts as a fixed reference point and where information on the current location of the user is stored. To reduce the overload on the HLR, the VLR was introduced.
Introduction to GSM
Visitor Location Register (VLR): The VLR is a database that contains a subset of the information located on the HLR. It contains similar information as the HLR, but only for subscribers currently in its Location Area. There is a VLR for every Location Area. The VLR reduces the overall number of queries to the HLR and thus reduces network traffic.
Figure 1.11: Visitor Location Register Equipment Identity Register (EIR): Each mobile equipment has a number known as the International Mobile Equipment Identity. This number, is installed in the equipment and is checked by the network during registration. According to the IMEI, the mobile may be allocated one of three states - allowed onto the network, barred access, or monitored.
There is only one EIR per network. It is composed of three lists. The white list, the gray list, and the black list.
12
13
OpenBTS
Figure 1.12: Equipment Identity Register Authentication Centre (AuC):
The AuC is a protected database that handles the authentication and encryption tasks for the network. The AuC generates 3 cryptovariables: RAND, SRES, and Kc. These cryptovariables are also known as the triplets. Although it is not required, the Auc is normally physically collocated with the HLR.
Introduction to GSM
SMS Gateway (SMS-G): Short Message Serving Center is the entity which does the job of storing and forwarding of messages to and from the mobile station. Chargeback Center (CBC): Provides a service or an activity of corporate-wide benefit for internal convenience o is organizationally established within its own contract o is accounted for as a distinct fully recoverable cost center
Full GSM Architecture:
14
15
OpenBTS
1.3 OSI Reference Model Under its official name, the Open Systems Interconnection Reference Model (known as the OSI model), was developed by the International Organization for Standardization (known as ISO). And, yes, the full acronym of the OSI is ISO OSI What is the OSI Model? The OSI model is a layered model that describes how information moves from networked device to another. When we communicate by telephone or letters, we usually are not concerned with the details of the physical transfer of the information. We just want to be able to send and receive information; in other words communicate. The same applies to the layers of the OSI Model; each layer has a fixed role in the process of communications. The OSI model deals with the following issues: How a device on a network sends/receives its data How a device on a network knows where to send/look for its data How devices on a network are physically connected to each other The 7 OSI Models: 1. 2. 3. 4. 5. 6. 7.
Physical Layer Data Link Layer Network Layer Transport Layer Session Layer Presentation layer Application Layer
The OSI model breaks the network communications process into seven separate layers according to, the following rules: 1. 2. 3. 4.
Each of the 7 layers has a unique task to perform Similar functions are all combined together in the same layer A layer uses the services and information of the layer below it only A layer provides serves and information to the layer above it only
Introduction to GSM
OSI Layers in details: 1.3.1 Physical Layer: The physical layer is at the bottom networking model. It deals with data that is in the form of electrical signals. The data bits are sent as 0's and 1's. 0's correspond to low voltage signals and 1's correspond to high voltage signals. The mechanical aspects of communication, such as wires or connectors come under this layer. The physical layer also deals with how these wires, connectors, and voltage electrical signals work. It associates with any part of the network structure that doesn't process information in any way. 1.3.2 The Data Link Layer: The transmission of the data over the communication medium is the responsibility of this layer. The 0's and 1's that are used in the communication are grouped into logical encapsulation. This encapsulation is called frames. The data is transported in frames. The responsibility of these frames is that of the data link layer. The Data Link layer accepts data from the Network Layer, packages that data into frames, and sends them to the Physical Layer for distribution. In the same way, it receives frames from the physical layer of a receiving computer, and changes them into packets before sending them to the Network Layer. 1.3.3 Network Layer: This layer is responsible for making routing decisions and forwards packets that are further than one link away. By making the network layer responsible for this function, every other layer of the OSI model can send packets without dealing with where exactly the system happens to be on the network, whether it be 1 hop or 10 hops away. In order to provide its services to the data link layer, it must convert the logical network address into physical machine addresses, and vice versa on the receiving computer. This is done so that no relaying, routing, or networking information must be processed by a level higher in the model then this level. The network layer is also responsible for determining routing and message priority. By having this single layer responsible for prioritization, the other layers of the OSI model remain separated from routing decisions. This layer is also responsible for breaking large packets into smaller chucks when the original packet is bigger than the Data Link is set. Similarly, it re-assembles the packet on the receiving computer into the original-sized packet.
16
17
OpenBTS
1.3.4 Transport Layer: The transport layer ensures quality and reliability of the communication. The data packet switching is entirely handled by the transport layer The transport layer's main duty is to ensure that packets are sent error-free to the receiving device in proper sequence with no data loss. This is accomplished by the protocol stack sending send and receive acknowledgements, and proper checksum/parity/synchronization of data being maintained. The transport layer is also responsible for breaking large messages into smaller packets for the network layer, and for re-assembling the packets when they are received from the network layer for processing by the session layer. 1.3.5 The Sessions Layer: The session layer is mainly responsible for creating, maintaining and destroying the communication link. The session layer also determines who can send data and who can receive data at every point in the communication. Without the dialogue between the two session layers, neither computer would know when to start sending data and when to look for it in the network traffic. 1.3.6 Presentation Layer: The presentation layer is responsible for protocol conversation, data translation, compression, encryption, character set conversion, and graphical command interpretation between the device and the network. There are various techniques of data compression which are used to send and receive the optimized data. For example, if certain data is repeating itself for a number of times, then it is logical to send the data only once, and specify the number of times it is repeated. This bundling of the repeated data is one of the techniques of compressions. The compression and decompression of the data is handled by the presentation layer. 1.3.7 Application Layer: This is the topmost layer of the OSI reference model. This layer comes into picture whenever a user invokes any application and all of the associated processes are run also, when an application wants to communicate with another application, then there has to be communication between these associated processes. The application layer is responsible for this communication. The application layer provides services that support user applications, such as database access, e-mail services, and file transfers.
Introduction to GSM
Summary of OSI Layer Functions:
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
• This layer serves as the window for users and application processes to access network services. It also identifies communication partners, determines resource availability, and synchronizescommunication.
• This layer is concerned with data representation and code formatting.
• The Session layer establishes, maintains, and manages the communication session between computers.
• The functions defined in this layer provide for the reliable transmission of data segments, as well as the disassembly and assembly of the data before and after transmission.
• The Network layer defines the processes used to route data across the network and the structure and use of logical addressing.
• This layer is concerned with the linkages and mechanisms used to move data about the network, including the topology, such as Ethernet or Token Ring, and deals with the ways in which data is reliably transmitted.
• This layer defines the electrical and physical specifications for the networking media that carry the data bits across a network.
18
19
OpenBTS
1.3.8 Protocol Stacks In order for each layer of the model to communicate with the levels above and below it, certain rules were developed. These rules are called Protocols, and each protocol assigns to a specific set of tasks /services to a specific layer of the model. Each layer of the model has its own set of protocols. When you have a set of protocols that create a complete OSI model, it is called a Protocol Stack. Each layer of the OSI model formats the data it receives to suit the functions to be performed on that layer. In general, the package of data that moves through the layers is called a Protocol Data Unit (PDU).
Layer
PDU Application
Data
Presentation
Data
Session
Data
Transport
Segments
Network
Packet
Data link
Fran
Physical
Bit
Figure 1.13: OSI Model and Protocol date unit
Introduction to GSM
When a message is sent from one device to another, it travels down the protocol stack/ model layers, and then up the layers of the other device. As the data travels down the stack, it picks up headers from each layer (Except the physical layer). Headers contain information that is read by the peer layer on the stack of the other device.
Figure 1.14: Data travel down in layer in it's way to send it. As the data travels up the levels of the peer device, each header is removed by its equivalent protocol. These headers contain different information depending on the layer they receive the header from, but tell the peer layer important information, including packet size and frames. Each layer's header and data are called data packages, or service data units. Although it may seem confusing, each layer has a different name for its service data unit.
20
21
OpenBTS
1.4 Structure of Air Interface in GSM 1.4.1 Radio Spectrum a scarce resource The radio interface is the interface between the mobile stations and the fixed infrastructure. It is probably the most important interface of the GSM system, as it is the key element to enable mobility and wireless access. One of the main objectives of GSM is roaming. Therefore, in order to obtain a complete compatibility between mobile stations and networks of different manufacturers and operators, the radio interface must be completely defined. As we know the radio spectrum is a limited resource shared by all users, the spectrum has administrative as well as economic, technical and physical parameters; the effective utilization of the spectrum requires favorable conditions at all 4 levels. One radio communication system is considered more "spectrum efficient" than another if it conveys the desired information using less of the spectrum resource. Spectrum efficiency also involves the arrangement of communication systems within the spectrum resource. In other words, the spectrum is used inefficiently when systems are not packed together as tightly as possible in frequency bands (as when excessive guard bands are used). The allocation of frequency bands, the development of channeling plans, and the assignment of frequencies to specific systems all affect spectrum efficiency.
1.4.2 Multiple Access Scheme: Since the radio frequency spectrum, is a finite natural resource that has greater demands placed on it every day. In an effort to make the most efficient use of this resource, various technologies have been developed so that multiple, simultaneous users can be supported in a finite amount of spectrum. This concept is called "multiple access." The three most commonly used access methods are frequency division multiple access (FDMA), time division multiple access (TDMA), and code division multiple access (CDMA). A mix of Frequency Division Multiple Access (FDMA) and Time Division Multiple Access (TDMA), combined with frequency hopping, has been adopted as the multiple access scheme for GSM. The TDMA multiple access scheme on a carrier frequency together with the GMSK modulation used by GSM, a 200KHz carrier spacing is required to provide the necessary bit rate per carrier frequency. The 200kHz carrier spacing yields 124 carriers from the 25MHz spectrum allocation. Because some of the energy in a GMSK modulated signal lies outside the nominal 200KHz band, GSM recommends that carriers 1 and 124 will not normally be used (guard band of 200 KHz) in order to protect services using adjacent spectrum bands.
Introduction to GSM
These 124 possible carriers are defined for the uplink (Fu) and downlink (Fd) as follows: Fu(n) = 890.2 MHz + 0.2(n-1) MHz (1< n < 124) Fd(n) = 925.2 MHz + 0.2(n-1) MHz (1< n < 124)
Figure 1.15: FDMA/TDMA concept
22
23
OpenBTS
1.4.3 TDMA Frame Structure: Each of the frequency carriers is divided into frames of 8 timeslots of approximately 577ms (15/26 ms) duration with 156.25 bits per timeslot. The duration of a TDMA frame is 4.615ms (577ms x 8 = 4.615 ms). The bits per timeslot and frame duration yield a gross bit rate of about 271kbps per TDMA frame. TDMA frames are grouped into two types of multiframes: 26-frame multiframe (4.615ms x 26 = 120 ms) comprising of 26 TDMA frames. This multiframe is used to carry traffic channels and their associated control channels. 51-frame multiframe (4.615ms x 51 @ 235.4 ms) comprising 51 TDMA frames. This multiframe is exclusively used for control channels. The multiframe structure is further multiplexed into a single superframe of duration of 6.12 seconds. This means a superframe consists of: 51 multiframes of 26 frames. 26 multiframes of 51 frames. The last multiplexing level of the frame hierarchy, consisting of 2048 superframes (2715648 TDMA frames), is a hyperframe. This long time period is needed to support the GSM data encryption mechanisms.
Figure 1.16: Frame Hierarchy
Introduction to GSM
1.4.4 What is a Burst? Each carrier frequency used in GSM is divided into 8 independent timeslots and into each of these timeslots a burst is placed. The modulating bit rate for a GSM carrier is 270.8 Kbits/s (1625/ 6 Kbits/s) which means that the timeslot of approximately 577ms corresponds to 156.25 bits. During the time slot period a frequency carrier is modulated by a stream of data bits organized into blocks, called a burst. A burst is made up of a useful part and a guard period. In the guard period nothing is transmitted and its purpose is to allow for a variation in the arrival time of the radio signal. The guard period avoids that adjacently (in time) received burst have their useful parts overlapping. If the useful parts of two received bursts overlap then their data will be corrupted. In addition to the guard period an adaptive time alignment process is used by the MS for all bursts except the access burst. This is used to vary the time of start of transmission of bursts to avoid overlapping with adjacent bursts at the receiver, e.g. BS. Five types of bursts are defined by GSM; four full bursts (i.e. with long useful parts) and one short burst Types of Bursts: Normal burst: This burst consists of 8.25 bits guard period and 116 data bits, the data bits may be encrypted, if encryption has been initiated by the network. The coded data bits correspond to two groups of 57 bits each, containing signaling or user data. The stealing flags (S) indicate to the receiver whether the information carried by the burst is traffic or signaling data. The training sequence has a length of 26 bits and is used for channel quality estimation and equalization. The remaining bits are used as start and stop tail bits. These tail bits are a group of three bits set to zero and placed at the beginning and the end of the burst. The tail bits are used to cover the periods of ramping up and down of the mobile transmitter‘s power amplifier.
Figure 1.17: Normal burst Frequency correction burst: This burst has the same guard period, start bits and stop bits as the normal burst, but instead of a sequence of encrypted data bits and training sequence, the remaining bits (142) form a fixed series of zeros. This burst is used for frequency synchronization of the mobile.
Figure 1.18: Frequency correction burst
24
25
OpenBTS
Synchronization burst: This burst is used for time synchronization of the mobile station. It contains the same start and stop bits as the frequency correction burst but uses an ‗extended training sequence‘ of 64 bits and a consequently reduced set of data bits.
Figure 1.19: Synchronization burst Dummy burst: This burst has the same structure as the normal burst but it carries no data. It is used in place of a normal burst when no other data need be sent. Access burst: This burst is used by the mobile for initial access to the system. The burst is shorter than the others, because it does not require the MS to be fully synchronous with the BS. It is characterized by an extended guard period of 68.25 bits to cater for burst transmission without knowledge the timing advance. The maximum spatial distance accommodated by the 68.25 bits is ca. 75.6km, which is well in excess of the maximum cell radius anticipated for GSM radio cells.
Figure 1.20: Access burst
Introduction to GSM
1.4.5 Timing Advance and Power Control: To simplify the design of the mobile, the GSM Recommendations specify an offset of three time-slots between the BSS and MS timing thus avoiding the necessity for the mobile to transmit and receive simultaneously. However, the synchronization of a TDMA system is critical because bursts have to be transmitted and received within the "real-time" time slots allotted to them. The further the MS is from the BSS then, obviously, the longer it will take for the bursts to travel the distance between them. The GSM BSS caters for this problem by instructing the MS to advance its timing (i.e. transmit earlier) to compensate for the increased propagation delay. This advance is then superimposed upon the 3 time-slot nominal offset, as shown in the following diagram. ―Power Control" allows the operator to not only compensate for the distance from MS to BSS, but can also cause the BSS and MS to adjust their power output to take account of that distance. The closer the MS is to the BSS, the less the power it and the BSS will be required to transmit. This feature saves radio battery power at the MS, and helps to reduce co-channel and adjacent channel interference. GSM Recommendations state that uplink power control is mandatory, whereas downlink power control is optional.
Figure 1.21: Timing Advance and Power Control
26
27
OpenBTS
The transfer of signaling information in GSM follows the layered OSI model (as previously explained):
Layer 1 (Physical Layer) Layer 2 (Data Link Layer) Layer 3 (Networking or Messaging Layer)
Introduction to GSM
1.5 GSM Air Interface Protocols: The diagram below shows the layer relationship between the MS - BTS. From the diagram we can see that traffic channels are catered for with other functional units. The Data Link Layer (Layer 2) is where the control channels are supported (PCH+AGCH, SACCH etc.); Layer 2 frames are also passed from the Data Link Layer to the Physical Layer. The Physical Layer also communicates directly to the Radio Resources Management layer for the purposes of channel assignment, physical system layer information (including, measurement results, timing advance etc).
Figure 1.22: Air interface protocol Air interface-Layer1: The Physical layer provides support for bit transfer over the air interface. Layer 1 services are offered to Layer 2 via a ‗logical gateway‘ known as a Service Access Point (SAP). The SAP provides both control (channel establishment and release) of the entity providing the service, and data bit transfer. GSM SAPs differ from OSI SAPs in that they are controlled by the Radio Resource Management Layer (RR - Layer 3) as opposed to the Data Link Layer (Layer 2). Each control channel used on the air interface has a SAP defined between the Physical Layer and Data Link Layer.
28
29
OpenBTS
Figure 1.23: Air interface Communication between Layer 1 and Layer 2 is achieved by the use of Primitives: • Request - Used by the layer requesting services from a lower layer. • Indication - When the services of a layer are requested, its activities are notified to the layer requesting via the Indication primitive. • Response - This is the acknowledgement by a layer of receipt of the Indication primitive. • Confirm - Once the requested services have been completed, the providing layer will inform the requesting layer via the Confirm primitive.
Figure 1.24: SAPs between the Physical Layer and the Data Link Layer
Introduction to GSM
1.6 GSM Control Channels What are Control Channels? Control channels are communication channels used in a system (such as a radio control channel), which are dedicated to the sending and/or receiving of command messages between devices (such as a base station and a mobile radio). On the GSM system, the control channel sends messages that include paging (alerting), access control (channel assignment) and system broadcast information (access parameters and system identification).
Control Channels
BCH Broadcast Channels
CCCH Common Control Channels
DCCH Dedicated Control Channels
BCCH
PCH
SDCCH
FCCH
RACH
SACCH
SCH
AGCH
CBCH
30
31
OpenBTS
Broadcast Channels (BCH): Broadcast Control Channel (BCCH) - DOWNLINK - This channel contains system parameters needed to identify the network and gain access. These parameters include the Location Area Code (LAC), the Mobile Network Code (MNC), the frequencies of neighboring cells, and access parameters. Frequency Correction Channel (FCCH) - DOWNLINK - This channel is used by the MS as a frequency reference. This channel contains frequency correction bursts. Synchronization Channel (SCH) - DOWNLINK - This channel is used by the MS to learn the Base Station Information Code (BSIC) as well as the TDMA frame number (FN). This lets the MS know what TDMA frame they are on within the hyperframe. Cell Broadcast Channel (CBCH) – DOWNLINK - The CBCH is for point-toomnipoint messages. It is used to broadcast specific information to network subscribers; such as weather, traffic, sports, stocks, etc. Messages are normally public service type messages or announcements. The CBCH isn't allocated a slot for itself; it is assigned to an SDCCH. It only occurs on the downlink. Common Control Channels (CCCH) Paging Channel (PCH) - DOWNLINK - This channel is used to inform the MS that it has incoming traffic. The traffic could be a voice call, SMS, or some other form of traffic. Random Access Channel (RACH) - UPLINK This channel is used by a MS to request an initial dedicated channel from the BTS. This would be the first transmission made by a MS to access the network and request radio resources. The MS sends an Access Burst on this channel in order to request access. Access Grant Channel (AGCH) - DOWNLINK - This channel is used by a BTS to notify the MS of the assignment of an initial SDCCH for initial signaling. Dedicated control channels: Standalone Dedicated Control Channel (SDCCH) - UPLINK/DOWNLINK - This channel is used for signaling and call setup between the MS and the BTS. Fast Associated Control Channel (FACCH) - UPLINK/DOWNLINK - This channel is used for control requirements such as handoffs. There is no TS and frame allocation dedicated to a FAACH. The FAACH is a burst-stealing channel, it steals a Timeslot from a Traffic Channel (TCH).
Introduction to GSM
Slow Associated Control Channel (SACCH) - UPLINK/DOWNLINK - This channel is a continuous stream channel that is used for control and supervisory signals associated with the traffic channels.
1.6.1 Air-interface - Layer 1 (SACCH) All SACCH blocks carry a 2 octet header at the physical layer. In the downlink direction, this contains the ‗ordered' power level and timing advance information. Ordered power control is given as a 5-bit number with a value of between 0 (maximum power) and 31. For stepping up of power, each value indicates an increase of power between 2dB, 4dB .......12dB, 14dB. For stepping down of power, each value represents a reduction of either 2dB or 4 dB. These steps are dependent on database parameter settings. The timing advance field is coded with a 7-bit number. ‗1111111' represents no TA information is given. If no timing advance is to be applied, then the value will be ‗0000000'. Values from decimal 1 to 63 relate to an increase in distance of 550m for each increase of 1. Decimal 64 to 126 are reserved values.
Figure 1.25: SACCH Block Format (UL & DL)
32
33
OpenBTS
1.6.2 Air-interface - Layer 2 The Data Link Layer is the OSI layer 2 entity on the air interface. The Data Link Layer provides services to Layer 3 and is served by the Physical Layer. 1.6.2.1 What‟s LAPDm? LAPDM stands for Link Access Protocol on Delta channel, m stands for modified. Where Delta channel rates are:16kb/s or 64 kb/s. The Data Link Layer uses LAPDm on all the control channels except the RACH. LAPDm is designed to specifically support: Multiple Layer 3 entities Multiple Physical Layer entities BCCH signaling PCH signaling AGCH signaling DCCH (SDCCH, SACCH, FACCH) signaling LAPDm includes functions for: Provision of single or multiple Data Link Connections on a Dm channel and the use of a Data Link Connection Identifier (DLCI) to discriminate between the links if more than one is provisioned Recognition of frame type Transparent message transfer between layer 3 entities The organisation of layer 3 information into frames Peer to Peer transmission of signalling data in defined frame formats Establishment, maintenance (supervision) and termination of one or more (parallel) signalling channels on data links Acknowledgement of transmission and reception of information frames (Iframes) Unacknowledged transmission and reception of Unnumbered Information frames (UI-frames) Flow control Detection of format and data errors on a data link Contention resolution when establishing data link after an access request has been made on the RACH
Introduction to GSM
Control Field Frame Formats: The control field indicates the frame type, sequence numbers and whether the frame is a command or response. • There are three types of control field format: I. Information format : used for numbered information transfer type frames (I-frames) between layer 3 entities II. Supervisory format :used for Data Link supervisory tasks such as Iframe acknowledgement, I-frame re-transmit request or I-frame transmission suspension III. Unnumbered format : Provides unacknowledged information transfer and additional Data Link control functions.
Figure 1.26: Frame Formats The P/F bit is used in both Command and Response frames. – In a Command frame, it is known as the ‗P' bit. – In Response frames, it becomes the „F' bit. When the Data Link layer requires a response from the far entity, it will set the ‗P' bit to ‗1' to indicate the that entity that a response is required. The responding entity will then set the ‗F' bit to „1' to indicate that this is the response. N(S) - Send Sequence Number This value identifies the frame number. It is used in I-frames only. N(R) - Receive Sequence Number This indicates the number of the next frame expected by the entity. It is used in both I-frames and S-frames. A value of N(R) received by an entity gives acknowledgement of all I-frames sent from that entity up to and including N(R)-1. S - Supervisory Function Bit(s) It is defined using bit 3 and 4 of the control field.
34
35
OpenBTS
Figure 1.27: supervisory commands/responses bits RR - Receiver Ready • The RR frame is used by the Data Link Layer entity to indicate: – it is ready to receive I frames – acknowledge previously received I frames up to and including N(R)-1 – Clear a busy condition which was previously indicated by a RNR frame sent by the same data link entity. • In addition an RR frame with the "P" bit set to a "1" may be used by the Data Link Layer entity to ask for the status of its peer Data Link Layer entity. • No information field is permitted in the RR frame. REJ - Reject Command/response • The REJ command is used to request retransmission of one or more I-frames. • The re-transmission should start with the frame number equal to N(R). • If bit 5 (P bit) is set to ‗1', this indicates a request for the status of the peer layer 2 entity. The REJ frame contains no information. RNR - Receiver Not Ready • The RNR frame is used by the Data Link Layer to indicate to the peer layer a busy condition, • for instance a full buffer that requires a temporary suspension of transmission from the peer entity. • As in the REJ frames, no information is permitted in the RNR frame. U - Unnumbered Function Bit
Introduction to GSM
Figure 1.28: Unnumbered Function Bit SABM • • • • • •
SABM is used to establish multi-frame acknowledged operation between layer 2 entities. Multi-frame operation must be established between two entities before Iframes can be exchanged. A SABM can also contain layer 3 information. SABM frame cannot carry segmented layer 3 information only an entire message. The distant entity will respond to a SABM normally with an unnumbered acknowledgement (UA) frame. On acceptance of the SABM, the entity will set both N(S) and N(R) to ‗0', if there are any unacknowledged I-frames, they will be discarded. The responsibility for recovery of this information lies with higher layers.
DISC - Disconnect Command Modes of Operation The DISC command is used to terminate multi-frame operation. The originating entity will cease multi-frame operation when it receives either a DM or UA from the distant entity. UI - Unnumbered Information Command • UI is used to transfer information without affecting the values of N(S) and N(R). • If a UI frame is lost, it is not recovered. • UI frames would be used where loss of the information within is not critical. UA Unnumbered Acknowledgement Response • When an entity is ready to accept I-frames via multiframe operation, it will reply to a SABM with the UA response. • UA can also be used to clear a previous RNR condition. DM - Disconnect Mode Response • If a condition exists whereby an entity is unable to continue multi-frame operation, it will respond to any valid command that it cannot action using the DM response. • The DM frame cannot carry layer 3 information.
36
37
OpenBTS
Length Indicator
Figure 1.29: Length Indicator
EL - Extension Bit • EL set to ‗0' indicates that there is more than one octet of Length Indication data. • If set to ‗1',this indicates that it is the last or only octet of Length Indication data. M - More Data Bits The M bit indicates whether the layer 3 information is segmented or not. • If set to ‗0' and the previous frame also had the M bit set to ‗0', this indicates that the frame contains a complete layer 3 message. • If the bit is set to ‗0' and the previous frame had it set to ‗1', this indicates that this frame contains the last segment of a segmented layer 3 message. • If the M bit is set to ‗1', all available information octets contain layer 3 information. Length - length Field bits • The value of bits 3 to 8 will indicate the number of octets of layer 3 information. • For format A frames, the length eld will always be coded ‗000000' i.e. there is no layer 3 information carried in the frame. • For format B frames, the length eld will be coded between ‗000001' and ‗010100' (decimal 1 - 20). • The maximum value possible for a frame carrying a SACCH message is ‗010010' (decimal 18). Information Field The information field may contain layer 3 data or fill bits. These fill bits are coded as follows: • Downlink - 2Bh (00101011) • Uplink - 2Bh or FF (11111111) - decided by the MS.
Introduction to GSM
1.6.2.2 Different modes of operation in Air interface-Layer2: 1. Unacknowledged Operation: In Unacknowledged mode, Unnumbered Information (UI) frames are used for the transfer of layer 3 information. The UI frames are not acknowledged by layer 2 and there is no error recovery or flow control procedures defined. 2. Acknowledged Operation: In Acknowledged mode, only one mode of information transfer is defined. This is Multiple Frame Operation. Each frame is acknowledged by the Data Link layer in the receiving entity. Error recovery and flow control procedures are defined. Any errors not recoverable by layer 2 are reported to layer 3. Layer 3 information is sent in numbered Information (I) frames and several frames may be sent before acknowledgement is received depending on the setting of the ‗k' value. Over the air interface, k=1 which requires that each Iframe is acknowledged before the transmission of the next. Multi-frame operation is initiated by the use of the Set Asynchronous Balanced Mode (SABM) command. In acknowledged mode, layer 2 can support segmentation of the layer 3 messages. If the layer 2 information field is not able to carry the entire layer 3 message, then the message will be broken down into blocks which can be reassembled at the receiving entity.
38
39
OpenBTS
1.6.2.3 Data Link Connection Identifier (DLCI) The DLCI consists of two elements: 1. Service Access Point Identifier The SAPI is carried in the address field of each frame and determines to which and from which Layer 3 entity a message is to be transported by Layer 2. On the air interface only two SAPI values (0 & 3) are currently supported, others may be defined in the future. The SAPI takes a specific value for the following functions on the Dm channel: SAPI = 0: CS Call Control Signalling (3GPP TS 24.008 ) Mobility Management Signalling (3GPP TS 24.008) Supplementary Services Signalling (3GPP TS 24.010) Radio Resource Management Signalling (3GPP TS 24.008) SAPI = 3 Short Message Services (3GPP TS 24.011) Priority of SAPIs On SDCCH: Highest priority: SAPI = 0 Lowest priority: SAPI = 3 On SACCH If there is a SAPI 3 frame awaiting transmission, then it will be sent after a SAPI 0 frame even if there are still SAPI 0 messages to be sent. In the downlink direction, any SAPI 3 must always be followed by at least one SAPI 0 message. Allowed SAPI's:
Introduction to GSM
2. Type of Control Channel: The type of control channel on which the Data Link Connection is to be established. This information is not carried in frames between Data Link Layer peer entities but is managed locally in each system and is carried in primitives between layers. Procedure for Transmission of Message Unit 1. The Network Layer (Layer 3) will select the appropriate SAP and DLCI. 2. The Network Layer (Layer 3) will indicate to the Data Link Layer which endpoint has been chosen. Procedure upon Receipt of a Message Unit 1. When the Data Link Layer Receives a frame containing a Layer 3 message unit, it will have also received from the Physical Layer an indication concerning the type of channel on which the message unit was received. 2. This combined information together with the SAPI will enable the Data Link Layer to deliver the Layer 3 message unit to the required Data Link connection endpoint of the indicated SAP.
40
41
OpenBTS
Signaling model showing channels SAPs and SAPIs:
Introduction to GSM
1.6.2.4 Frame Format Peer-to-Peer Communication:
Format A. Format B. Format Bbis. Format C.
Format A: This format is used on a DCCH for frames where there is no real Layer 3 information to be transmitted. It often occurs that Layer 2 (the receiving entity) does not have a Layer 3 message to send after receiving a frame, which requires acknowledging, from its peer. The Layer 2 entity will simply transmit an empty frame to acknowledge receipt of the last frame, but as yet does not have any information to send in response. The empty frame will contain ll bits, coded with the hexadecimal value 2B or FF.
Figure 1.30: Format A:
42
43
OpenBTS
Format B: This format is used on a DCCH for frames containing an information field.
Figure 1.31: Format B Format Bbis: This format is used only on BCCH, PCH and AGCH. Only used in the unacknowledging mode of signaling data transfer.
Figure 1.32: Format Bbits
Introduction to GSM
Format C: The random access procedure is not LAPDm. Layer 3 is responsible for generating the 8 bit information content of the random access burst and using the primitives will pass this information to the Data Link Layer, the primitives will also contain which type of channel to use. In the previously mentioned formats there were some fields such as: • Address Field. • Control Field. • Length Indicator Field. • Information Field. Address Field: The address field identifies the intended receiver within a command frame, and the transmitter of the response frame.
Figure 1.33: Address Field
EA - Address Extension - set as in LAPDm where a ‗1' indicates that this is the final octet in the address field. If coded as a ‗0', then there is more Address information to come. C/R - In the downlink, if coded as a ‗1' indicates that this is a command frame. if coded ‗0' then it is a response frame. In the downlink, these values are reversed as in LAPDm. Command/response field bit (C/R): identifies the frame as either a command or response frame. Service Access Point Identifier (SAPI)
44
45
OpenBTS
The SAPI identifies a point at which data link layer services are provided and consequently the Layer 2/3 boundary. The following SAPI's are defined for use on the A-bis interface. SAPI 0= Call control procedures (normally referred to as the RSL) SAPI 62= Operation and Maintenance procedures (OML) SAPI 63= Layer 2 management procedures (L2ML) Terminal Endpoint Identifier (TEI) The TEI identifies a unique function or element within the BSS.
Introduction to GSM
1.6.3 Air Interface-Layer 3: Layer 3 of the air interface is responsible for several signaling functions: • Connection management (CM) which comprises: Call Control (CC) Short Message Service Support (SMS) Supplementary Services Support (SS) • Mobility Management (MM) • Radio Resource Management (RR) A Protocol Discriminator (PD) is used to identify which route the message is to take and for CM messages, a Skip indicator is also specified. The different classes of services provided by the Signaling Layer 3 at the MS side are accessible at the following Service Access Points: • Registration Services at the MM REG SAP. • CC services for normal and emergency calls including call related Supplementary Services at the MNCC-SAP. • Short Message Services support services at the MN SMS-SAP. • Call Independent Supplementary services, support services at the MNSS-SAP. The registration services (location - updating IMSI attach/detach) are provided at the service access point MM REG-SAP. These services are provided by and can be directly accessed at the MM sub-layer.
46
47
OpenBTS
1.6.3.1 Radio Resource Management:
Figure 1.34: Radio Resource Management The Radio Resource sub-layer is responsible for establishing, maintaining and release of dedicated Radio Resource connections. RR responsible for: • Channel Assignment Procedures Channel Release • Channel Change and Handover Procedures • Change of: – Channel Frequencies – Hopping Sequences • Measurement Reports • Power Control Timing Advance Modification of Channel Modes (speech and data) • Cipher Mode Setting The main areas of responsibility are: • Radio frequency spectrum management • System reactions in response to radio environment changes • Subscriber to PLMN channel maintenance RR involves: Primarily the BSC and BTS. The MSC only when handover is between cells managed by different BSC's.
Introduction to GSM
1.6.3.2 Mobility Management Sub-layer: The Mobility Management Sub-layer is responsible for functions related to a subscriber but not related to RR functions. Tasks include: Authentication Registration Subscriber Mobility Checks for subscribed services Security Location Update Procedure Periodic Updating IMSI Attach Procedure IMSI Detach Procedure TMSI Reallocation Procedure Identification Procedure Connection Management Sub-layer: • Like MM,CM uses the connection that RR provides for information exchange. • The Connection Management sub-layer is composed of: – Call Control (CC) – Short Message Service (SMS – Supplementary Service (SS) Call Control: – Call establishment procedure for mobile originated calls – Call establishment procedures for mobile terminated calls – Call re-establishment after interruption of a Mobility Management connection – Dual-Tone Multi-frequency (DTMF) control procedure for DTMF transmissions Supplementary Services: – Specific variations of the way the basic service is provided to the user ( call forwarding and multiparty call). Short Message Services: – Provision of Point-to-Point Short Message Service
48
49
OpenBTS
1.6.3.3 Layer 3 - Frame Structure:
Introduction to GSM
The 3 main elements of a standard layer 3 message are:
The Protocol Discriminator identifies the layer 3 protocol that the message belongs to. It is made up of the rest 4 bits of octet 1 of the standard layer 3 message. Bits: 4321 0 0 1 1 - Call Control; SS messages (call related) 0 1 0 1 - MM messages 0 1 1 0 - RR management messages 1 0 0 1 - SMS messages 1 0 1 1 - SS messages (non-call related) 1 1 1 1 - Reserved for procedures as per TS GSM 11.10
Skip Indicator: • The second half-octet (bits 5-8) of the layer 3 header octet 1 are used to distinguish between MM/RR and CC messages. • For MM and RR, they make up the Skip Indicator. If set to ‗0000', the message is assumed to be either MM or RR. • Any message sent by either MM or RR will set have the Skip Indicator set to ‗0000' by the transmitting entity. • If a message is received with the Skip Indicator any value other than ‗0000', it will be ignored by MM or RR.
50
51
OpenBTS
• •
Transaction Identifier: The TI is used to distinguish between possible multiple parallel CM connections and transactions The TI is composed of the TI flag and 3 bits for the TI value.
Figure 1.36: Skip Indicator Message Type (Air Interface) • Octet 2 of the layer 3 header identifies the message type as per 3GPP TS 24.008. • The message type defines either MM, RR or CM messages. • If the message is RR, bits 1-7 are coded with the message type. If the message is either MM or CM, only bits 1-6 are coded with the message type. Message Sequence Scenarios: • Mobile originating call establishment • Mobile terminating call establishment • Location updating • Call clearing
Introduction to GSM
1.6.4 Mobile Originating Call A Mobile Originated Call is a call that is initiated by the MS. The following example is a mobile-originated call that terminates outside the PLMN. 1. The MS sends a Channel Request (CHAN_REQ) message on the RACH. 2. The BSS responds with a radio resource assignment (IMM_ASS_CMD) on the AGCH. 3. The MS sends a Service Request (CM_SERV_REQ) message to the BSS on the SDCCH.
Figure 1.37: Mobile Originating Call Authentication 4. Before the network will provide any services to the MS, the network will require the MS to authenticate itself. The BSS sends an Authentication Request (AUTH_REQ) message to the MS. The RAND serves as the "challenge" for authentication. 5. The MS calculates the proper SRES based on the RAND that was given and sends the SRES to the BSS in an Authentication Response (AUTH_RESP) message. 6. The BSS verifies the SRES. If the SRES is correct then the MS is authenticated and allowed access to the network. The BSS will send a Service Accept (CM_SERV_ACC) message letting the MS know that the service request was received and processed. 7. Once authenticated, the BSS orders the MS to switch to cipher mode with the CIPH_MOD_CMD message.
52
53
OpenBTS
Figure 1.38: Authentication Initial Call Set Up: 8. The MS will immediately switch to cipher mode and send a Cipher Mode Complete (CIPH_MOD_COM) message. 9. The MS then sends a Call Setup (SETUP) message to the BSS. The message includes the address information (MSISDN) of the called party. 10. The BSS assigns a TCH to the MS by sending an Assignment Command (ASS_CMD) message. This message includes which Transceiver (TRX) and which Time Slot (TS) to use. *The BSS does not actually assign a TCH to the MS until the MSC sends a Call Proceeding (CALL_PROC) message to the BSS indicating that the IAM has been sent. 11. The MS immediately switches to the assigned TCH. The MS sends an Assignment Complete (ASS_COM) message back to the BTS on the FACCH. *Remember that a FACCH is not a separate channel, it is simply a stolen time slot from the TCH that is used for signaling data instead of voice traffic.
Introduction to GSM
Figure 1.39: Initial Call Set Up Call Establishment: 16. Once the MSC receives the ACM, it sends an ALERT message to the MS indicating that the call is going through. The BSS sends the ALERT message on the FACCH. Once the MS receives the ALERT, it will generate the ringing sound in the earpiece. The BSS sends an alerting message the subscriber will hear the line ringing. 17. Once the called party answers the phone, the PSTN will send an Answer message to the MSC. The MSC forwards this to the MS in a Connection (CON) message. 18. Once the MS receives the CON message, it switches over to voice and begins the call. All voice traffic occurs on the assigned TCH.
Figure 1.40: Call Establishment
54
55
OpenBTS
Call Termination: 19. When either the caller or the called party hangs up, the call will be disconnected. Either party can initiate the disconnect. In this example, the MS initiates the disconnect. The MS sends a Disconnect (DISC) message to the BTS on the FACCH. 20. The BSS forwards the DISC to the MSC. Once the MSC receives the DISC message, it sends a Release (REL) message through the GMSC to the PSTN as well as down through the BSS to the MS. 21. The MS responds by sending a Release Complete (REL_COM) message to the BSS on the FACCH. The BSS forwards the REL_COM message up to the MSC. Once the MSC receives the REL_COM message the call is considered ended from the call control perspective. 21. Although the call has ended, the BSS still has a TCH allocated to the MS. The MSC sends a Channel Release (CHAN_REL) message to the BSS. The BSS forwards the CHAN_REL message to the MS. 22. The MS responds with a DISC (LAPDm) message and returns to an idle mode. The BSS deallocates the channel and releases the TRX.
Figure 1.41: Call Termination
Introduction to GSM
Figure 1.42: Summary for Mobile Originating Call
56
57
OpenBTS
1.6.5 Mobile Terminating Call Call Establishment:
In this example, the call is originating from outside the PLMN. Route Establishment to find the MSC/VLR The calling party dials the MSISDN for the mobile subscriber. The PSTN identifies the network (PLMN) that the dialed MSISDN belongs to and will locate a GMSC for that network. The PSTN sends an Initial Address message to the GMSC. The GMSC forwards the MSISDN to the HLR and requests routing information for it. The HLR looks up the MSISDN and determines the IMSI and the SS7 address for the MSC/VLR that is servicing the MS. The HLR then contacts the servicing MSC/VLR and asks it to assign a Mobile Station Routing Number (MSRN) to the call. The MSC/VLR allocates the MSRN and forwards it to the HLR. Note: It is important to remember that the MSC/VLR assigns a MSRN to the call not to the MS itself. The HLR forwards the MSRN as well as routing information for the servicing MSC/VLR to the GMSC. The GMSC sends an Initial Addressing message to the servicing MSC/VLR and uses the MSRN to route the call to the MSC/VLR. Once the servicing MSC/VLR receives the call, the MSRN can be released and may be made available for reassignment. Paging the Mobile Station The MSC/VLR then orders all of its BSCs and BTSs to page the MS. Since the MSC/VLR does not know exactly which BSC and BTS the MS is monitoring, the page will be sent out across the entire Location Area.
Introduction to GSM
Initial Setup The MS receives the Page Request (PAG_REQ) on the PCH. The MS recognizes that the page is intended for it, based on a TMSI or an IMSI. The MS sends a Channel Request (CHAN_REQ) message on the RACH. The BSS responds on the AGCH by sending an Immediate Assignment (IMM ASS) message which assigns an SDCCH to the MS. At this point, the network does not know that the MS is the one that it is paging, it only knows that this MS wants access to the network. The MS immediately switches to the assigned SDCCH and sends a Paging Response (PAG_RES) message on the SDCCH. This lets the network know that the MS is responding to its page. Authentication Before the network will provide any services to the MS, the network will require the MS to authenticate itself. The BSS sends an Authentication Request (AUTH_REQ) message to the MS. The RAND serves as the "challenge" for authentication. The MS calculates the proper SRES based on the RAND that was given and sends the SRES to the BSS in an Authentication Response (AUTH_RESP) message. The BSS verifies the SRES. If the SRES is correct then the MS is authenticated and allowed access to the network. Once the MSC/VLR has authenticated the MS, it will order the BSS and MS to switch to cipher mode using the CIPH_MOD_CMD message. Once the MS in encryption mode, the VLR will normally assign a new TMSI to the MS. Establishing a Channel Once the MS is authenticated and in encryption mode, The MSC sends a Setup Message to the BSS, the BSS forwards the SETUP message to the MS on the assigned SDCCH.the assigned SDCCH. The SETUP message may include the Calling Line Identification Presentation (CLIP), which is essentially caller ID. The MS responds by sending a Call Confirmed (CALL_CON) message; which indicates that the MS is able to establish the requested connection. The BSS relays the message up to the MSC. Call Setup The BSS then sends an Assignment Command (ASS_CMD) message to the MS on the assigned SDCCH. The ASS_CMD message assigns a Traffic Channel (TCH) to the MS. The MS immediately switches to the TCH and responds with an Assignment Complete (ASS_COM) message on the FACCH. The MS begins ringing once it has established the TCH. Remember that all signaling that occurs on the traffic channel actually occurs on a FACCH, which is a time slot that is stolen from the TCH and used for signaling. The MS sends an ALERT message to the MSC on the FACCH. The BSS forwards the
58
59
OpenBTS
ALERT message through the PSTN to the calling party and the caller hears the line ringing. Call Establishment Once the user answers the call (by pressing the send button), the MS will send a Connect CON message to the MSC. The Connect message is forwarded back to the caller's switch to activate the call. The MSC sends a Connect Acknowledge CON_ACK message to the MS and the call is established. Call Disconnect Disconnect happens the same way as for any other call. In this example, the calling party initiates the disconnect. When the calling party hangs up, the calling party's switch initiates a Release (REL) message. The message is forwarded to the serving MSC, which is then forwarded to the BSS. The BSS will send a Disconnect (DISC) message to the MS on the FACCH. The MS confirms release of the call by sending a Release (REL) message on the FACCH, which is forwarded to the MSC. The MSC sends e Release Complete (REL_COM) message through the BSS to the MS. As far as call control (CC) is concerned, the connection has been terminated. The MS still has a TCH assigned to it, so the BSS sends a Channel Release (CHAN_REL) message to the MS. This releases the radio resource on the Air Interface. The MS responds be sending a final Disconnect message and returns to idle.
Introduction to GSM
Figure 1.43: Summary for Mobile Terminating call:
60
61
OpenBTS
1.6.6 Location Update: There are 3 types of location update: 1. Location Updating, Type Normal: The MS listens to the system information, compares the Location Area Identity (LAI) to the one stored in the MS on the SIM card (on BCCH channel if idle or SACCH channel if active) and detects whether it has entered a new location area or is still in the same location area. If the broadcast LAI differs from the one stored on the SIM card, the MS must perform a location update, type normal: 1) The MS sends a channel request message including the reason for the access. Reasons other than location updating can be for example, answering a page or emergency call. 2) The message received by the BTS is forwarded to the BSC. The BSC allocates an SDCCH, if there is one idle, and tells the BTS to activate it. 3) The MS is now told to tune to the SDCCH. 4) The MS sends a location updating request message that contains the identity of the MS, the identity of the old location area and the type of updating. 5) The authentication parameter is sent to the MS. In this case the MS is already registered in this MSC/VLR and the authentication parameter used is stored in the VLR. (If the MS is not already registered in this MSC/VLR the appropriate HLR or the previously used MSC/VLR must be contacted to retrieve MS subscriber data and authentication parameters) 6) MS sends an answer calculated using the received authentication parameter. 7) If the authentication is successful, the VLR is updated. If needed, the HLR and old VLR are also updated. 8) The MS receives an acceptance of the location updating. 9) The BTS is told to release the SDCCH. 10) The MS is told to release the SDCCH and switches to idle mode. In cases where the MS is busy when it changes location area, it receives the information about the new LAI on the SACCH. The location updating takes place after the call is released. The MS must set up a new connection and perform the procedures described in the previous case. 2. Location Updating, Type IMSI attach: IMSI attach is a procedure and is used by the MS to notify the system that it was powered on. The procedure is described below: 1) The MS requests an SDCCH. 2) The system receives the IMSI attach message from the MS. 3) The MSC sends the IMSI attach message to the VLR.The VLR removes the IMSI detached flag and resumes normal call handling for the MS. (Notice that IMSI attach is the complement to the IMSI detach procedure. 4) The VLR returns the IMSI attach acknowledge message to the MSC. 5) The MS also receives an acknowledge message.
Introduction to GSM
Notice: The procedure is to be used only when the IMSI detach flag is set in the VLR, not in the HLR. If the flag is set in the HLR, switching to active mode requires a normal location updating of the MS. In most GSM system, the detached flag is stored in the VLR and no information is passed to the HLR. 3. Location Updating, Type periodic registration: Periodic registration is a type of location updating procedure that is used to avoid unnecessary paging of the mobile in cases where the MSC never receives the IMSI detach message and also to prevent damage in case of database failure. The procedure is described below: 1) MS listens on the BCCH to specify if Periodic Registration Location Update is used in the cell. If periodic registration is used, the MS is told how often it must register. The time is set by the operator and can have values from 0 to 255 decihours (a unit of six minutes). If the parameter is equal to zero, periodic registration is not used in this cell. If the parameter is set to ten, for example, the MS must register every hour. 2) Both the MS and the MSC have the timer which controls the procedure. When the timer in the MS expires, the MS performs a location updating, type periodic registration. After that, the timers in MS and MSC restart. In the MSC there is a time scanning function for the MSs. If the MS does not register within the determined interval plus a guard time, then the scanning function in MSC detects this and the MS is flagged as detached.
62
63
OpenBTS
Figure 1.44: Summary for Location Update:
Introduction to GSM
1.6.7 Call Clearing: There are 2 types of call clearing: 1. Call Clearing Initiated by the Net
Chapter 2: About OpenBTS 2.1 Introduction The OpenBTS Project is an effort to construct an open-source Unix application that uses the Universal Software Radio Peripheral (USRP) to present a GSM air interface (―Um‖) to standard GSM handset and uses the Asterisk VoIP PBX to connect calls. This is in fact very different from a conventional GSM BTS, which is a dumb device that is managed externally by a base station controller (BSC) and connects calls in a remote mobile switching center (MSC). Because of this important architectural difference, the end product of this project is better referred to as an access point, even though the project is called ―OpenBTS‖. According to David Burgess, founder of OpenBTS, in an interview in the emerging communications conference (eComm): ―We know, from public records and interviews with former employees of cellular carriers in Africa, we know the actual cost of service in Africa is something on the order of $5 or $6 per month, per subscriber. We believe in those same environments, the type of network we're talking about [openBTS] can be operated at an order of magnitude lower cost. You could have profitable operations at around $1 per subscriber.‖ OpenBTS also serves as an excellent internal communication tool for field engineers & technicians using mobilephones, as an alternative to walkie-talkie and other classic systems, inwork fields of limited area.
2.2 What‟s OpenBTS? OpenBTS stands for Open Base Transceiver Station. It is an open-source UNIX application that uses the Universal Software-Radio Peripheral (USRP) to present a GSM air interface ("Um") to standard GSM handsets and uses the Asterisk® software PBX to connect calls. [1] As shown in Fig 2.1, the OpenBTS uses the USRP hardware to receive and transmit the GSM signaling. This is done by using the GNU Radio framework. Asterisk is used to interface the GSM calls between the cellular phones under the OpenBTS network. Any other device that can be connected to Asterisk can be also used. Generally speaking, OpenBTS consists of a USRP board connected on a USB port of a Linux machine running Asterisk, GnuRadio and OpenBTS. [2]
2.3 Main Components & Their Functions a. Hardware I. Computer We have done several testing on a laptop powered by Intel dual-core 1.7 GHz and 2 GBs of RAM and it worked totally fine. Some other implementations were done on ARM test-boards, Android phones
66
67
Secure OpenBTS
II. USRP The USRP is a hardware designed by Ettus Research to allow general purpose computers to function as high bandwidth software radios. In essence, it serves as a digital baseband and IF section of a radio communication system. [3] The USRP used for our implementation was USRP ver 1, having the following specifications:[4]
8 MHz of instantaneous RF bandwidth Lowest cost solution USB connectivity MIMO with a single USRP device the motherboard has two daughterboard slots FPGA: Altera Cyclone ADCs: 12-bits 64 MS/s DACs: 14-bits 128 MS/s
III. Daughterboards Daughterboards turn a USRP or USRP2 motherboard into a complete RF transceiver system. Just add an antenna, and you are ready for two-way, high bandwidth communications in many popular frequency bands. [5] There are several daughterboards that can be used with the USRP covering from DC to 5.9 GHz. For OpenBTS, we can use the RFX900, to cover the GSM 850 and 900 bands, or the RFX1800, to cover the GSM 1800 and 1900 bands. [3] Normally, OpenBTS needs two daughterboards, however there‘s a patch[2] that can be used to allow OpenBTS to work using a single daughterboard. IV. Antenna(s) At least two VERT900 are needed. One for TX and another for RX. VERT900 is a 9-inch. 824960 MHz, 1710-1990 MHz Quad-band Cellular/PCS and ISM Band vertical antenna having 3dBi Gain and it‘s ideal for both RFX900 and RFX1800. [3] Due to the strong on-board RF gain, our tests proved that OpenBTS can work with reduced signal strength and coverage with no antennas at all, however this is not recommended. V. Mobile Station Any unlocked cellular phone can be used. Nokia DCT-3 series phones are most preferred as they include the field-test mode, known as ―Netmonitor‖. Netmonitor can be used to force the mobile station to limit its network search to a certain ARFCN. It can also be used for many other monitoring and troubleshooting purposes. To learn how to enable Netmonitor on Nokia DCT-3 phones, you may check Due to some problems with the stock clock shipped with the USRP, some phones don‘t succeed in finding or registering to OpenBTS. Netmonitor is mainly used to force phones to camp to a certain ARFCN regardless of clock frequency errors. Most phones (especially smartphones) that were manufactured in 2011 were discovered to work
About OpenBTS
on OpenBTS with no problems. [6] VI. Sim Card(s) OpenBTS should work using any SIM card from any operator, as long as the phone is manually set to register to OpenBTS rather than any other existing network(s). However, for certain applications (like the one this book is based on), programmable SIM cards are used. Of course, in case of using programmable SIM Cards, SIM Card reader/writer will be needed. b. Software[3] I. UNIX or UNIX-like OS Preferably Ubuntu Linux. OpenBTS should also work on Mac OS X. II. OpenBTS Mainly as a GSM stack. III. GNURadio To interface with the USRP on the software-level. IV. Asterisk (or FreeSwitch) Asterisk is an open-source VoIP PBX server that OpenBTS uses by default to connect local and external calls. Other PBX servers like FreeSwitch can also be used. [8] V. C++ Boost libraries Used in some parts of the OpenBTS source-code. 2.4 Clock Modification According to [7], In most GSM implementations, the symbol clock is derived from a 13 MHz ―stratum 3‖ OCXO with a frequency accuracy on the order of 20 ppb. (A VCTCXO in the handset is slaved to the OXCO in the BTS via the FCCH.) The standard USRP clock is a lowcost 64 MHz crystal oscillator. This poses two problems for OpenBTS: 1. The USRP standard clock is not well-matched to the GSM symbol rate. In the current OpenBTS implementation, the software radio includes a resampler for rate-matching, but this is an additional computational cost that should be eliminated. 2. The USRP standard clock is not stable enough for use in multi-BTS networks. The drift of the crystal oscillator may even be outside the frequency search range of some GSM phones. To solve the second problem, the USRP main board should be modified to use a more accurate external clock source according to 2.5 Installation of OpenBTS on Linux (Ubuntu) (Copied from [3] after making few edits) 2.5.1 GNU Radio Installation a. Installing the dependencies: sudo apt-get update sudo apt-get -y install swig g++ automake1.9 libtool python-dev
b. Getting and installing boost libraries: wget http://kent.dl.sourceforge.net/sourceforge/boost/boost_1_37_0.tar.gz tar xvzf boost_1_37_0.tar.gz cd boost_1_37_0 BOOST_PREFIX=/opt/boost_1_37_0 ./configure --prefix=$BOOST_PREFIX --withlibraries=thread,date_time,program_options make sudo make install c. Getting and installing GNURadio: cd ~ wget ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.3.0.tar.gz tar -zxf gnuradio-3.3.0.tar.gz cd gnuradio-3.3.0 ./configure --with-boost-include-dir=$BOOST_PREFIX/include/boost-1_37/ make make check sudo make install sudo mv ~/gnuradio-3.3.0 /usr/local/share Note:
GnuRadio is also available for download through the GUI front-end for aptitude, Synaptic Package Manager, found in the ―System‖ menu under ―Administration‖. It's preferred to use the latest version of GnuRadio.If a newer version than the one presented here is found, please download it from http://gnuradio.org/releases/gnuradio or ftp://ftp.gnu.org/gnu/gnuradio. To install it on your PC, extract it run INSTALL. Removing an old GnuRadio installation on Ubuntu or other Debian-based Linux systems can be done either by referring to the ―Synaptics Package Manager‖, selecting gnuradio and choosing ―Mark for Complete Removal‖ then clicking ―Apply‖, or by simply running ―sudo apt-get remove gnuradio‖
About OpenBTS
2.5.2 OpenBTS installation a. Installing the dependencies: sudo apt-get install asterisk libosip2-dev libortp7-* b. Getting the source code: download the last version available online from [1] and save it in your home directory or any other preferred working directory. c. Installing: tar -zxf openbts-2.6.0Mamou.tar.gz mv openbts-2.6.0Mamou openbts-2.6.0 cd openbts-2.6.0 export LIBS=-lpthread ./configure make sudo make install 2.5.3 Adding user permissions to work with the USRP: sudo addgroup usrp sudo addgroup usrp echo 'ACTION=="add", BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002", GROUP:="usrp", MODE:="0660"' > tmpfile sudo chown root.root tmpfile sudo mv tmpfile /etc/udev/rules.d/10-usrp.rules Alternatively, this step can also be done using GUI by referring to ―Users & Groups‖ available in the Ubuntu ―Administration‖ menu, then adding a group called ―usrp‖ (if not there already). Make sure that the ―usrp‖ group has the current user of the machine marked as a user of this group, in the ―Properties‖ window. 2.5.4 Testing the USRP: Restart the computer (it should work without it, but even restarting the udev service, the USRP worked with user privileges only by restarting the machine): sudo reboot Connect the USRP to the USB port cd /usr/local/share/gnuradio-3.3.0/gnuradio-examples/python/usrp ./usrp_benchmark_usb.py
70
71
Secure OpenBTS
The output should be similar to this: Check if the maximum throughput between USB and USRP is 32MB/sec. Testing 2MB/sec... usb_throughput = 2M ntotal = 1000000 nright = 998435 runlength = 998435 delta = 1565 OK Testing 4MB/sec... usb_throughput = 4M ntotal = 2000000 nright = 1998041 runlength = 1998041 delta = 1959 OK Testing 8MB/sec... usb_throughput = 8M ntotal = 4000000 nright = 3999272 runlength = 3999272 delta = 728 OK Testing 16MB/sec... usb_throughput = 16M ntotal = 8000000 nright = 7992153 runlength = 7992153 delta = 7847 OK Testing 32MB/sec... usb_throughput = 32M ntotal = 16000000 nright = 15986239 runlength = 15986239 delta = 13761 OK Max USB/USRP throughput = 32MB/sec
About OpenBTS
2.6 Finding an Unused Frequency Band Luckily, GnuRadio is shipped with a built-in ―Spectrum Analyzer‖ script. The script file name is usrp_spectrum_sense.py and can be found in the examples/usrp directory inside the gnuradio root directory. usrp_spectrum_sense.py can be used to find out the available frequencies. Practically speaking, usrp_fft.py script (fig. 2) should be used instead [3] as it includes a userfriendly GUI. To run , you have to type the following command in terminal: $ usrp_fft.py -f 1.7838G & where 1.7838 GHz is the centre frequency used.
Kalibrate may also be used to determine vacant frequency bands in a certain area by using the ―GSM Base Station Scan‖ mode for scanning the whole GSM spectrum in this area for BCCH signals of any nearby BTS and avoiding using the used frequencies by those BTSs. For example, to use Kalibrate for scanning the GSM-850 band: $ src/kal -s 850 The output should be similar to: kal: Scanning for GSM-850 base stations. GSM-850: chan: 128 (869.2MHz - 13Hz) power: chan: 131 (869.8MHz + 7Hz) power: chan: 139 (871.4MHz + 10Hz) power: chan: 145 (872.6MHz 7Hz) power:
9400.80 4081.75 2936.20 33605.48
2.7 Configuring OpenBTS To configure OpenBTS to run for the first time, it‘s required to open the apps/OpenBTS.config.example with the most preferred editor then save the file as OpenBTS.config after making the following modifications. ● The GSM.MCC (Mobile Country Code) should be set according to your country. In our case it is 602(Egypt). To avoid any problems with the current operators, it‘s highly recommended to use 001 as it‘s reserved for testing purposes. ● The GSM.MNC (Mobile Network Code). A good way to check it is by scanning the network with the phone and checks the operator‘s code. Normally it‘ll be showed in the MCC-MNC format (e.g. 602 07). This means that the country is Egypt and network code is 07.
72
73
Secure OpenBTS
To avoid any problems with the current operators, it‘s highly recommended to use 01 as it‘s reserved for testing purposes. ● The GSM.Band defines the frequency band that the OpenBTS will operate on. The best is to use a band not allocated in your region, but sometimes this is not possible. If it‘s your case, you‘ll need to check using a Spectrum Analyzer as shown previously, what is the band has a free space. You can use USRP as Spectrum Analyzer for low cost. Now we can set the GSM.ARFCN (Absolute RF Channel) as the ARFCN for the band we are willing to use. Legal Notice: It‘s highly recommended to refer to the telecom laws and regulations in your country before running OpenBTS, to avoid any legal complications.
The OpenBTS.config file should like this: (Modifications are bolded) # Sample OpenBTS configuration file. # Formatting rules: # Configuration values are defined with line of the form # The key name can contain no spaces. # Everything between the first space and the end of the line becomes the value. # Numeric values can be preceded with "0x" for hex. # Blank lines are OK. # Lines starting with "#" are comments. # By default, configuration values can be changed but not removed after initialization. # Lines starting with "$" are directives that define other properties of config values: # "static" -- configuration value cannot be changed or removed after initialization. # "optional" -- configuration value may be removed after initialization. # As a gerenal rule, non-valid configuration values will crash OpenBTS. # So be cafeful. # # Logging and reporting parameters # # The initial global logging level: ERROR, WARN, NOTICE, INFO, DEBUG, DEEPDEBUG Log.Level INFO # Logging levels can also be defined for individual source files. # This example set shows normal operations in the control layer (L3). Log.Level.MobilityManagement.cpp INFO $optional Log.Level.MobilityManagement.cpp Log.Level.CallControl.cpp INFO $optional Log.Level.CallControl.cpp Log.Level.RadioResource.cpp INFO $optional Log.Level.RadioResource.cpp # The log file path. If not set, logging goes to stdout.
About OpenBTS
Log.FileName test.out #$static Log.FileName # LOG(ALARM) is printed and also sent as udp to this address. Log.Alarms.TargetIP 192.168.10.200 $optional Log.Alarms.TargetIP Log.Alarms.TargetPort 10101 # Number of alarms saved in internal queue Log.Alarms.Max 10 # Wireshark support # OpenBTS writes L2 GSMTAP messages to this port. # If GSMTAP.TargetIP is not defined, this output is disabled. GSMTAP.TargetIP 127.0.0.1 $optional GSMTAP.TargetIP # The standard IANA for GSMTAP is 4729. This can be used to override that. #GSMTAP.TargetPort 4729 # Indications port # Some interal operations produce status reports sent to this port. # This can be the same as the Alarm target. Indications.TargetIP 127.0.0.1 Indications.TargetPort 10202 # Port number for test calls. # This is where an external program can interact with a handset via UDP. TestCall.Port 28670 # # Transceiver parameters # # Transceiver interface # This TRX.IP is not really adjustable. Just leave it as 127.0.0.1. TRX.IP 127.0.0.1 $static TRX.IP # This value is hard-coded in the transcevier. TRX.Port 5700 $static TRX.Port Just leave it alone. # Path to transceiver binary # If this is not defined, you will need to start the transceiver by hand. # YOU MUST HAVE A MATCHING libusrp AS WELL!! TRX.Path ../Transceiver/transceiver #TRX.Path ../Transceiver52M/transceiver #$static TRX.Path
74
75
Secure OpenBTS
# TRX logging. # Logging level. # IF TRX.Path IS DEFINED, THIS MUST ALSO BE DEFINED. TRX.LogLevel ERROR #$static TRX.LogLevel # Logging file. If not defined, logs to stdout. # TRX.LogFileName test.out #$static TRX.LogFileName # # SIP, RTP, servers # # Asterisk PBX Asterisk.IP 127.0.0.1 Asterisk.Port 5060 $static Asterisk.IP $static Asterisk.Port # Messaging server Smqueue.IP 127.0.0.1 Smqueue.Port 5063 $static Smqueue.IP $static Smqueue.Port # Local SIP/RTP ports # OpenBTS binds to these ports. SIP.Port 5062 $static SIP.Port RTP.Start 16484 RTP.Range 98 $static RTP.Start $static RTP.Range # If Asterisk is 127.0.0.1, this is also 127.0.0.1. # Otherwise, this should be the local IP address of the interface used to contact asterisk. # In other words, this is the IP address at which Asterisk will see OpenBTS. SIP.IP 127.0.0.1 # # Special extensions. # # Routing extension for emergency calls. # This must be defined, even if you are not supporting emergency calls. # PBX.Emergency 2101 # # SIP parameters
About OpenBTS
# # SIP registration period in seconds. # Ideally, this should be slightly longer than GSM.T3212. SIP.RegistrationPeriod 7200 # # SIP Internal Timers. All timer values are given in millseconds. # These are from RFC-3261 Table A. # # SIP Timer A, the INVITE retry period, RFC-3261 Section 17.1.1.2 # in milliseconds # For fast SMS interactions, keep this at 2000 or more. SIP.Timer.A 2000 # # SMS parameters # # ISDN address of source SMSC when we fake out a source SMSC. SMS.FakeSrcSMSC 0000 # ISDN address of destination SMSC when a fake value is needed. SMS.DefaultDestSMSC 0000 # The SMS HTTP gateway. # Comment out if you don't have one or if you want to use smqueue. # SMS.HTTP.Gateway api.clickatell.com # IF SMS.HTTP.Gateway IS DEFINED, SMS.HTTP.AccessString MUST ALSO BE DEFINED. # SMS.HTTP.AccessString sendmsg?user=xxxx&password=xxxx&api_id=xxxx # Things to query during registration updates. #Control.LUR.QueryIMEI $optional Control.LUR.QueryIMEI #Control.LUR.QueryClassmark $optional Control.LUR.QueryClassmark # Does everyone get a TMSI, registered or not? Control.LUR.TMSIsAll $optional Control.LUR.TMSIsAll # TMSI table controls # Maximum number of TMSIs to track Control.TMSITable.MaxSize 10000 # Maximum allowed ages of a TMSI, in hours. Control.TMSITable.MaxAge 72 # Want persistent TMSIs? Control.TMSITable.SavePath TMSITable.txt $optional Control.TMSISavePath # Open Registration and Self-Provisioning # If this is defined, the network accepts LUR from unprovisioned handsets. # This is required to support SMS-based auto-provisioning.
76
77
Secure OpenBTS
# This is a boolean -- either defined or not. Control.OpenRegistration $optional Control.OpenRegistration # # # # # # "Welcome" messages sent during IMSI attach attempts. ANY WELCOME MESSAGE MUST BE LESS THAN 138 CHARACTERS. ANY DEFINED WELCOME MESSAGE MUST ALSO HAVE A DEFINED SHORT CODE. Comment out any message you don't want to use. # The message sent upon full successful registration, all the way through the Asterisk server. # THIS MESSAGE IS NORMALLY REQUIRED FOR COMPLIANCE WITH AGPLv3. Control.NormalRegistrationWelcomeMessage Welcome to OpenBTS! AGPLv3 openbts.sf.net. Your IMSI is Control.NormalRegistrationWelcomeShortCode 0000 # Then message sent to accpeted open registrations. # IF OPEN REGISTRATION IS ENABLED, THIS MUST ALSO BE DEFINED. # THIS MESSAGE IS NORMALLY REQUIRED FOR COMPLIANCE WITH AGPLv3. Control.OpenRegistrationWelcomeMessage Welcome to OpenBTS! AGPLv3 openbts.sf.net. Your IMSI is # If you use SMS auto-provisioning, use that short code as the return address here. Control.OpenRegistrationWelcomeShortCode 101 # Then message send to failed registrations. #Control.FailedRegistrationWelcomeMessage Your handset is not provisioned for this network. $optional Control.FailedRegistrationWelcomeMessage Control.FailedRegistrationWelcomeShortCode 1000 # # GSM # # Network and cell identity. # Network Color Code, 0-7 # Also set GSM.NCCsPermitted later in this file. GSM.NCC 0 # Basesation Color Code, 0-7 GSM.BCC 2 # Mobile Country Code, 3 digits. # MCC MUST BE 3 DIGITS. Prefix with 0s if needed. # Test code is 001. GSM.MCC 001 # Mobile Network Code, 2 or 3 digits. # Test code is 01. GSM.MNC 07 # Location Area Code, 0-65535 GSM.LAC 1000 # Cell ID, 0-65535 GSM.CI 10
About OpenBTS
# Network "short name" to display on the handset. # This is optional, but must be defined if you also want to # send current time-of-day to the phine. GSM.ShortName OpenBTS $optional GSM.ShortName # A boolean telling whether or not to show country initials with the name. GSM.ShowCountry $optional GMS.ShowCountry # Assignment type for call setup. # The default is early assignment. # If defined, this will cause us to use very early assignment instead. #GSM.VEA $optional GSM.VEA # Band and Frequency # Valid band values are 850, 900, 1800, 1900. GSM.Band 900 $static GSM.Band # Valid ARFCN range depends on the band. GSM.ARFCN 80 # GSM.ARFCN 7 works on some phones in el center elli odam el forn # GSM.ARFCN 7 # ARCN 975 is inside the US ISM-900 band and also in the GSM900 band. #GSM.ARFCN 975 # ARFCN 207 was what we ran at BM2008, I think, in the GSM850 band. #GSM.ARFCN 207 $static GSM.ARFCN 2.8 Installing & Configuring smqueue To compile you first have to install g++-4.3: sudo apt-get install g++-4.3 Then, in OpenBTS/smqueue/Makefile.standalone: Modify g++ -o smqueue $(CPPFLAGS) $(INCLUDES) smqueue.cpp smnet.cpp smcomm... to become g++-4.3 -o smqueue $(CPPFLAGS) $(INCLUDES) smqueue.cpp smnet.cpp smcomm... (In this step we’re instructing gcc to use g++-4.3 instead of g++ for compiling the file) Finally, we will compile smqueue by issuing the following command: sudo make -f Makefile.standalone Note:
By default, OpenBTS is configured to accept only 7 - 12 digit phone numbers on autoprovisioning. This can easily be modified by setting the values of SC.Register.Digits.Max and SC.Register.Digits.Min at openbts/smqueue/smqueue.config.
78
79
Secure OpenBTS
2.9 Asterisk Configuration a. Backup the /etc/extensions.conf and /etc/sip.conf: cd /etc/asterisk sudo cp extensions.conf extensions.conf_ori sudo cp sip.conf sip.conf_ori b. Copy ~/openbts-2.3/AsteriskConfig/extensions.conf and sip.conf to the /etc/asterisk: sudo cp ~/openbts-2.3/AsteriskConfig/sip.conf . sudo cp ~/openbts-2.3/AsteriskConfig/extensions.conf . c. Edit the /etc/asterisk/extension.conf: Add the following to the end of the file: …........ [sip-local] exten => 2102,1,Macro(dialSIP,IMSI602*) exten => 2103,1,Macro(dialSIP,IMSI602*) ….......
d. Edit the /etc/asterisk/sip.conf: …........ ;provisioned Thu Mar 17 05:32:43 2011 [IMSI60203*] callerid=2102 canreinvite=no type=friend context=sip-local allow=gsm host=dynamic dtmfmode=info ;provisioned Thu Mar 17 05:36:13 2011 [IMSI60201*] callerid=2103 canreinvite=no type=friend context=sip-local allow=gsm host=dynamic dtmfmode=info …......... e. Restart the Asterisk: sudo /etc/init.d/asterisk restart
About OpenBTS
2.10 Software Architecture of OpenBTS [7] These are the directories: apps OpenBTS application binaries. Asterisk configuration files for use with OpenBTS. This file contains example AsteriskConfig Asterisk configuration files for the OpenBTS Asterisk server. This file does not contain REAL configuration files, since those would include real IMSIs. CLI
This is the directory for the OpenBTS command line interface.
CommonLib
Common-use libraries, mostly C++ wrappers for basic facilities, most of which are not specific to GSM.
Control
Control-layer functions for the protocols of GSM 04.08 and SIP. Most GSM L3 and VoIP messages terminate here. Everything in this directory should be in the Control namespace. Components: -- RadioResource. -- MobilityManagement. -- CallControl.
doc
Project documentation.
GSM
The GSM stack.
SIP
Components of the SIP state machines ued by the control layer.
smqueue
RFC-3428 store-and-forward server for SMS. Smqueue has different build dependencies than OpenBTS and so it has its own make file outside of the standard openbts autobuild system. This allows smqueue to be built without installing GNU Radio.
SMS
The SMS stack.
Transceiver
The software transceiver and specific installation tests.The transceiver consists of three modules: --- transceiver --- radioInterface --- USRPDevice
The interface between the GSM stack and the radio.Each TRX Manager UDP TRXManager socket interface represents a single ARFCN.The per-ARFCN control interface uses a command-reponse protocol.
About apps directory : * OpenBTS.cpp: it contains main function. * OpenBTS.config.example: Sample OpenBTS configuration file. About GSM directory : That is directory where most of our work is on. This is a small description for the included files: * GSML1FEC.h & GSML1FEC.cpp: L1, ―PHYSICAL LAYER‖, the radio modem, time-division multipexing, and error-correcting coding, GSM 04.04 and GSM 05.xx series.
80
81
Secure OpenBTS
* GSML2LAPDm.h & GSML2LAPDm.cpp: L2, ―DATA LINK LAYER‖, link layer addressing, segmentation and retransmission , GSM 04.05 and 04.06, ITU-T Q.921. * GSML3Message.h & GSML3Message.cpp: Description of standard L3 messages, GSM 04.07 * GSML3CommonElements.h & GSML3CommonElements.cpp: Common information elements, GSM 04.08 Sec. 10.5.1. * GSML3CCMessages.h & GSML3CCMessages.cpp: Messages for circuit-switched call control, GSM 04.08 Sec.9.3, ITU-T Q.931. * GSML3CCElements.h & GSML3CCElements.cpp:Call control information elements, GSM 04.08 Sec. 10.5.4. * GSML3MMMessages.h & GSML3MMMessages.cpp: Messages for mobility management, 04.08 Sec. 9.2. * GSML3MMElements.h & GSML3MMElements.cpp: Mobility management information elements, GSM 04.08 Sec. 10.5.3. * GSML3RRMessages.h & GSML3RRMessages.cpp: Messages for Radio Resources management, GSM 04.08 Sec. 9.1. * GSML3RRElements.h & GSML3RRElements.cpp: Radio Resource management information elements, GSM 04.08 Sec. 10.5.2. * GSMLogicalChannel.cpp & GSMLogicalChannel.cpp: A complete logical channel. Includes processors for L1, L2, L3, as needed. The layered structure of GSM is defined in GSM 04.01. The concept of the logical channel and the channel types are defined in GSM 04.03. * GSMEncryption.h: contatain A3A8 algorithm and A5/1 algorithm. * GSMTransfer.h & GSMTransfer.cpp: Data transfer objects for the GSM core. * GSMTDMA.h & GSMTDMA.cpp: A description of a channel's multiplexing pattern From GSM 05.02 Clause 7. Classes for GSM directory: Classes for GSML1FEC: * GSM::L1Encoder Abstract class for L1 encoders. In most subclasses, writeHighSide() drives the processing. Definition at line 81 of file GSML1FEC.h. Inheritance from L1Encoder classes GeneratorL1Encoder [FCCHL1Encoder, SCHL1Encoder], XCCHL1Encoder [CCCHL1Encoder, NDCCHL1Encoder (BCCHL1Encoder), SACCHL1Encoder, TCHFACCHL1Encoder]
About OpenBTS
* GSM::L1Decoder An abstract class for L1 decoders. writeLowSide() drives the processing. Definition at line 200 of file GSML1FEC.h. Inheritance from L1Decode classes RACHL1Decode, XCCHL1Decoder [ SDCCHL1Dencoder, SACCHL1Decoder, TCHFACCHL1Decoder] * GSM::L1FEC The L1FEC encapsulates an encoder and decoder. Definition at line 327 of file GSML1FEC.h. Inheritance from L1FEC classes CCCHL1FEC, LoopbackL1FEC, NDCCHL1FEC [ BCCHL1FEC, FCCHL1FEC, RACHL1FEC, SCHL1FEC], SACCHL1FEC, SDCCHL1FEC, TCHFACCHL1FEC, TestL1FEC. Classes for GSML2LAPDm: * GSM::L2DL Skeleton for data link layer (L2) entities. This is a base class from which the various channel classes are derived. Many derived classes are "thin" and do not implement full LAPDm. This is especially true of the downlink-only classes which do not have equivalents in Q.921 and HDLC. Definition at line 63 of file GSML2LAPDm.h. Inheritance from L2DL classes CCCHL2, L2LAPDm [FACCHL2, SACCHL2, SDCCHL2]
Classes for GSMLogicalChannel: * GSM::LogicalChannel Definition at line 65 of file GSMLogicalChannel.h. Inheritance from LogicalChannel classes L3LoopbackLogicalChannel, NDCCHLogicalChannel [CCCHLogicalChannel], SACCHLogicalChannel, SDCCHLogicalChannel [SDCCHLogicalChannel_LB], TCHFACCHLogicalChannel [TCHFACCHLogicalChannel_UPLINK]
Classes for GSML3Messages: * GSM::L3Messages This is virtual base class for the messages of GSM's L3 signalling layer. It defines almost nothing, but is the origination of other classes. Definition at line 59 of file GSML3Message.h. Inheritance from L3MMMessages classes L3MMMessages, L3RRMessages, L3CCMessages. * GSM::L3ProtocolElement Abstract class used for GSM L3 information elements. See GSM 04.07 Sec.11.2.1.1.4 for a description of TLV element formatting. Definition at line 175 of file GSML3Message.h.
Classes for GSML3MMMessages: * GSM::L3MMMessage This a virtual class for L3 messages in the Mobility Management protocol. These messages are defined in GSM 04.08 Sec. 9.2 Definition at line 49 of file GSML3MMMessages.h. Inheritance from L3MMMessages classes L3CMReestablishmentRequest, L3CMServiceAccept,L3CMServiceReject, L3CMServiceAbort, L3CMServiceRequest, L3IdentityRequest, L3IdentityResponse, L3IMSIDetachIndication, L3LocationUpdatingAccept, L3LocationUpdatingReject,
Classes for GSML3RRMessages: * GSM::L3RRMessage This a virtual class for L3 messages in the Radio Resource protocol. These messages are defined in GSM Sec. 04.08 9.1. Definition at line 47 of file GSML3RRMessages.h. Inheritance from L3RRMessages classes L3ApplicationInformation, L3AssignmentCommand, L3AssignmentComplete, L3AssignmentFailure, L3ChannelModeModify, L3ChannelModeModifyAcknowledge, L3ChannelRelease, L3ChannelRequest, L3ClassmarkChange, L3ClassmarkEnquiry, L3GPRSSuspensionRequest, L3ImmediateAssignment, L3ImmediateAssignmentReject, L3MeasurementReport, L3PagingRequestType1, L3PagingResponse, L3CipheringModeCommand, L3CipheringModeComplete, L3RRStatus, L3SystemInformationType1, L3SystemInformationType2, L3SystemInformationType3, L3SystemInformationType4, L3SystemInformationType5, L3SystemInformationType6. Classes for GSML3CCMessages: * GSM::L3CCMessage This a virtual class for L3 messages in the Call Control protocol. These messages are defined in GSM 04.08 Sec. 9.3. GSM call control is based on and nearly identical to ISDN call control. ISDN call control is defined in ITU-T Q.931. Definition at line 49 of file GSML3CCMessages.h. Inheritance from L3CCMessages classec L3classesAlerting, L3CallConfirmed, L3CallProceeding, L3CCStatus, L3Connect, L3ConnectAcknowledge, L3Disconnect, L3EmergencySetup, L3Hold, L3HoldReject, L3Progress, L3Release, L3ReleaseComplete, L3Setup, L3StartDTMF, L3StartDTMFAcknowledge, L3StartDTMFReject, L3StopDTMF, L3StopDTMFAcknowledge. Anther classes: * GSM::L3RejectCause RejectCause, GSM 04.08 Sec. 10.5.3.6 Definition at line 86 of file GSML3MMElements.h. * GSM::L3RRCause RRCause, GSM 04.08 Sec. 10.5.2.31. Definition at line 514 of file GSML3RRElements.h. * GSM::L3MobileIdentity Mobile Identity, GSM 04.08 Sec. 10.5.1.4. Definition at line 106 of file GSML3CommonElements.h. * GSM::L3LocationAreaIdentify LAI, GSM 04.08 Sec. 10.5.1.3. Definition at line 67 of file GSML3CommonElements.h.
About OpenBTS
* GSM::L3Cause Cause, GSM 04.08 10.5.4.11 Read the spec closely: we only have to support coding standard 3 (GSM), and that format doesn't carry the "recommendation" field. Definition at line 186 of file GSML3CCElements.h. * GSM::GSMError A base class for GSM exceptions. Definition at line 57 of file GSMCommon.h. Inheritance from GSMError classes L2ReadError, L2WriteError,L3ReadError, L3WriteError, RRLPReadError, SMSReadError. Common Function for Messages: * int MTI() const { return (int)LocationUpdatingRequest; } Return the messag type indicator * size_t bodyLength() const; Return the expected message body length in bytes, not including L3 header. * void parseBody( const L3Frame &src, size_t &rp ); The method starts processing at the first byte following the message type octet in the L3 message, which the caller indicates with the readPosition argument. If not defined, this will assert at runtime. * void text(std::ostream&) const; Generate a human-readable representation of a message. * void writeBody( L3Frame &dest, size_t &wp ) const; The method defined in some subclasses. If not defined, this will assert at runtime. About Control directory: * CallControl.cpp: Functions for CC (mobile originated, mobile terminated) * MobilityManagement.cpp: Functions for MM procedures (CM service, location updating) * RadioResource.cpp: Functions for RR procedures (paging, access grant) and in it we can determine the channel type needed. * SMSControl.cpp: Controller for SMS MOSMS (Mobile Originated Short Message Service): The MS "submits" a message that OpenBTS then "sends" to the network, and MTSMS (Mobile Terminated Short Message Service): OpenBTS "receives" a message from the network that it then "delivers" to the MS. * DCCHDispatch.cpp: Dispatch the appropriate controller for a Mobility Management message and for a Radio Resource message. Functions for MobilityManagement.cpp: * void Control::CMServiceResponder(const L3CMServiceRequest* cmsrq, LogicalChannel* DCCH) Controller for CM Service requests, dispatches out to multiple possible transaction controllers. Definition at line 54.
84
85
Secure OpenBTS
* void Control::IMSIDetachController(const L3IMSIDetachIndication* idi, LogicalChannel* DCCH) Controller for the IMSI Detach transaction, GSM 04.08 Sec. 4.3.4. Definition at line 83. *bool sendWelcomeMessage(const char* messageName, const char* shortCodeName, const char *IMSI, SDCCHLogicalChannel* SDCCH) Send a given welcome message from a given short code. Returns: true if it was sent. Definition at line 115. * void Control::LocationUpdatingController(const L3LocationUpdatingRequest* lur, SDCCHLogicalChannel* SDCCH) Controller for the Location Updating transaction, GSM 04.08 Sec. 4.4.4. Definition at line 115. Functions for RadioResource.cpp: * void Control::AccessGrantResponder( unsigned RA, const GSM::Time& when, float RSSI, float timingError) Decode RACH bits and send an immediate assignment.Definition at line 119. * void Control::PagingResponseHandler(const L3PagingResponse* resp, LogicalChannel* DCCH) Find and compelte the in-process transaction associated with a paging repsonse. Definition at line 232. * void Control::AssignmentCompleteHandler(const L3AssignmentComplete *confirm, TCHFACCHLogicalChannel *TCH) Find and compelte the in-process transaction associated with a completed assignment. Definition at line 296.
Functions for CallControl.cpp: MOC * void Control::MOCStarter(const L3CMServiceRequest* req, LogicalChannel *LCH) Run the MOC to the point of alerting, doing early assignment if needed. This function starts MOC on the SDCCH to the point of TCH assignment. Definition at line 567. * void Control::MOCController(TransactionEntry& transaction, TCHFACCHLogicalChannel* TCH) Complete the MOC connection.Continue MOC process on the TCH. Definition at line 797. MTC * void Control::MTCStarter(TransactionEntry& transaction, LogicalChannel *LCH, L3MobileIdentity mobID) Run the MTC to the point of alerting, doing early assignment if needed. Definition at line 918. * void Control::MTCController(TransactionEntry& transaction, TCHFACCHLogicalChannel* TCH).
About OpenBTS
Complete the MTC connection.Definition at line 1083. Note in Coding:
When describing layers (L1, L2, L3) we will refer to the ―low‖ side of the layer as the side the interfaces closer to the hardware and the ―high‖ side as the side that interfaces to higher-level functions. In a BTS, the the low-to-high direction is ―uplink‖ and the high-tolow direction is ―downlink‖. In the MS, those labels are reversed. To enforce good testing practices, we recommend the following: • Use assert() calls liberally to insure internal consistency. Do not continue once an unresolvable error condition is identified. • Build unit test fixtures for every component in the system. Do not check in code that does not pass the unit tests. It would be especially nice if someone could automate this testing process. • If you know there‘s a potential problem in a piece of code, use a ―FIXME‖ comment. If you leave something undone, use a ―TODO‖ comment. • Use the bug tracking system. That‘s why it‘s there.
2.11 Using OpenBTS The main OpenBTS binary can be run by simply going to the apps directory and executing: $ ./OpenBTS To enable SMS support, the built-in SMS queuing server should also be executing by going to the smqueue directory and running: $ ./smqueue
When the phone is registered on a network it gets a TMSI (Temporary Mobile Subscriber Identity). TMSI is randomly assigned by the VLR to every mobile in the area. It‘s good to clear the TMSI to get the first registration on the OpenBTS. A way to do it is to turn off the phone and take off the battery.
Put your mobile phones on and force the phone to use the OpenBTS network. To do so: 1. Nokia: Go to tools → Settings → Phone → Network. Select GSM only (not dual mode, nor 3G) and select operator manually (not automatically). OR Settings → Phone →Operator selection → Manual. 2. Wait for a while, while the phone is scanning available networks. You should see the OpenBTS network 602-07. Select it. 3. Wait again, the OpenBTS network should send you a welcome SMS. The exact message depends on the configuration of OpenBTS (openbts.config)
When you choose the OpenBTS network from the networks list on your phone, your phone connects to the network, but it doesn't register it's IMSI and it doesn't reserve a phone number. To do this, you have to send an SMS to 101 from your phone including the number you wish to have. For example, if I want my number on OpenBTS to be 2102, I'll just type 2102 on my
86
87
Secure OpenBTS
phone as SMS and send it to 101. So I did it and in less than a minute, It a confirmation SMS saying that my phone number is now registered as 2102.
You are ready to use the phones.
Typing ‗help‘ in the same terminal window where OpenBTS is running returns the following menu: alarms chans exit load page rxgain setlogfile unconfig
calls config findimsi noise power sendrrlp testcall uptime
cellid configsave help notices regperiod sendsms tmsis version
Important commands & their usage:
Command
Usage/Function
sendsms
sendsms -- send SMS to , addressed from , after prompting.
