ADVANCED DISTRIBUTED DECT-SIP

Transcription

1 MULTICELL NETWORKS based on DECT and CAT-iq Part 3/3 ADVANCED DISTRIBUTED DECT-SIP INTERWORKING UNIT FOR MULTI-CELL SYSTEMS Author Sarath Chandran Radhakrishnan DOSCH&AMAND Department of Electrical Engineering Technology FH Rosenheim Prof. Dr.-Ing. Holger Stahl Advisors Dirk Kelbch DOSCH&AMAND Dr.-Ing. Franz Dosch DOSCH&AMAND

2 Abstract Digital Enhanced Cordless Telecommunication (DECT) is a digital wireless technology standard, which is mainly used for cordless phone systems. DECT networks can be connected to other networks using an Interworking Unit (IWU). Session Initiation Protocol (SIP) is a signalling protocol used for Voice communication over the Ethernet. This paper discusses the design for an advanced distributed DECT- SIP Interworking unit with support for mobility management interfacing on SIP network. The existing models of DECT-SIP interworking units use some kind of central management entity to distribute the authentication information and in some cases even the data. This paper explores a way to do away with the need for such a management entity. In this report a detailed analysis of the message mapping between the DECT messages and SIP transactions is carried out and presented. The way of using DECT identities like IPUI (International Portable User Identity) to derive globally unique SIP identities is discussed. It is also necessary that both SIP and DECT security techniques should be kept intact when designing an IWU. Call flow models with the interworking unit are also analysed. Using the analysis results, a Distributed DECT/ SIP Interworking Unit is designed and implemented. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 2

3 Table of Contents ABSTRACT TABLE OF CONTENTS INTRODUCTION PROBLEM STATEMENT AND DESIGN GOALS SCOPE APPROACH STRUCTURE OF THE THESIS DIGITAL ENHANCED CORDLESS TELECOMMUNICATION (DECT) DECT NETWORK DECT Fixed Part (FP) Portable Part (PP) DECT PROTOCOL STACK LAYERS Physical Layer (PHL) Medium Access Control Layer (MAC) Data Link Control Layer (DLC) Network Layer (NWK) DECT PROTOCOL STACK PLANES Control Plane User Plane IDENTITIES AND SECURITY FP Identities PP Identities MAC IDENTITIES Fixed MAC identity (FMID) Portable MAC identity (PMID) NETWORK LAYER Mobility Management Call Control (CC) Call Independent Supplementary Services (CISS) Connection-Oriented Message Service (COMS) Connectionless Message Services (CLMS) Link Control Entity Messages (LCE) DECT CALL FLOW HANDOVER MECHANISM IN DECT NETWORK External handover Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 3

4 3 SESSION INITIATION PROTOCOL (SIP) INTRODUCTION ADDRESSING REQUESTS SIP REGISTER method SIP INVITE method RESPONSES SIP COMPONENTS User Agent Registrar Redirect server Proxy server CALL FLOW OVERVIEW OF EXISTING MULTICELL DECT-SIP INTERWORKING ARCHITECTURE THEORETICAL ANALYSIS OF THE ARCHITECTURE PROPOSAL OF AN ADVANCED ARCHITECTURE FOR DECT-SIP IWU SYSTEM ARCHITECTURE IDENTITY MAPPING DECT SIP MESSAGE MAPPING Outgoing call From PP to SIP client Incoming call PP Initiated Call termination Remote client initiated Call termination Re-registration ROAMING SCENARIO HANDOVER SCENARIO FOR DECT CONNECTION HANDOVER HANDOVER SCENARIO FOR DECT EXTERNAL HANDOVER IMPLEMENTATION OF THE PROPOSED ARCHITECTURE FINALIZING THE SIP STACK PJSIP Sofia SIP Asterisk as a SIP client SOFTWARE TOOLS USED ASTERISK General Asterisk software architecture SOFTWARE IMPLEMENTATION Registry Monitor thread using MySQL API DECT channel driver design Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 4

5 7 TEST SET UP TEST ARCHITECTURE ARCHITECTURE OF SINGLE CELL TEST SCENARIOS Registration of the Handset to the SIP server Outgoing call from Handset to SIP Phone Incoming call to the Handset from SIP Phone Test results CONCLUSION FUTURE WORK FEHLER! TEXTMARKE NICHT DEFINIERT. APPENDIX A.1 MYSQL OVERVIEW A.1.1 MySQL Commands A.2 REFERENCES A.3 LIST OF ABBREVIATIONS A.4 LIST OF FIGURES A.4 LIST OF TABLES Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 5

6 1 Introduction Digital Enhanced Cordless Telecommunication (DECT) has become the de-facto standard for cordless telephony since its inception on Although DECT originated in Europe, It has become popular worldwide. It is based on a micro-cellular radio communication system that provides low-power radio access between DECT handsets and base stations. An interesting feature of DECT is that it can also interwork with other type of networks like the following: Public switched telephone network (PSTN) Integrated Services Digital Network (ISDN) Global System for Mobile Communications (GSM) Internet Protocol networks (IP networks ) Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 6

7 Figure 1 Typical IP-DECT Network The above setup includes an IP PBX server which connects the local VoIP telephony network with the ISDN network. The Base station or Radio Fixed Part (RFP) terminates the IP layer and provides the DECT air interface for the mobile handsets. DECT-IP interworking units utilize Voice over Internet Protocol (VoIP) to carry the voice information over the IP networks like Local Area Network (LAN) and Internet. In most cases VoIP uses H.323 or SIP for signalling. RTP is used for the real time data traffic. DECT/ SIP systems use the DECT air interface for reliable wireless voice and data communication between DECT handsets and base stations and SIP on the Ethernet backbone. 1.1 Problem Statement and Design Goals In order to design a DECT- SIP interworking unit, a detailed and comprehensive mapping of DECT messages and SIP transactions is to be carried out and used. DECT and SIP both uses different techniques to ensure authentication and registration of user. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 7

8 The DECT system uses the Authentication Key (K) to identify and authenticate the valid users that are part of the system. So sharing of this key is necessary to support roaming between the FPs that are in the same network. This in turn demands the deployment of a management entity which stores all the authentication information relevant to the system and shares this information whenever a Visiting Fixed Part (VFP) requests for this information, so that it can identify a PP as a valid user. This technique however has some drawbacks, such as security vulnerabilities in storing such sensitive information in a central unit and the possibility of overloading the unit when multiple requests are made. Using an additional resource to make the DECT-SIP interworking unit can be avoided. So using the already existing SIP gateway to store the registration and authentication information and effectively doing away with the management entity is one of the design goals of this paper. SIP and DECT are two diverse protocols in their operation and in their objective. It is a tedious task to establish a correlation between their user authentication mechanisms and call handling capabilities. 1.2 Scope It is required in this master thesis to achieve the following: Propose a method to derive a globally unique SIP URI for every DECT handset from its DECT identity and map the authentication mechanism on the SIP side to every successful DECT subscription. Design the complete architecture of a multi-cell DECT-SIP interworking system supporting the following functionalities: o Mobility Support pre-call mobility Support handover (active call mobility) Implement the proposed design by developing a prototype and demonstrate the working of the system 1.3 Approach The thesis plan involved the following phases. Planning & Study phase o Defining the problem and the objectives of the thesis o Study of DECT and SIP DECT call flow, identities, security and handover SIP call flow, identities and session mobility Analysis of the other architectures o Study the other designs o Analyse the drawbacks o State why a new design is required Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 8

9 Proposal of a solution and improved architecture Prototyping the proposed architecture with the available tools Test the implementation, present the results and comment on how to improve the design further to make the system better 1.4 Structure of the thesis To present the work in an organized manner the thesis report is structured in the following way: The chapter 1 discusses the problem to be solved and the goals of the thesis. Chapters 2 and 3 present the background literature about DECT and SIP protocols. In chapter 4, an analysis of the existing DECT- SIP interworking unit implementations are presented and their approach of solving the issue is discussed. A new architecture proposal to solve the issue with a different approach and its advantages over the other architectures are presented in chapter 5. Implementation of the proposed design is discussed in chapter 6. Chapter 7 presents the tests carried out and the results. Finally, chapter 8 arrives at a conclusion of the thesis work done and how the work can be improved in the future if need be. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 9

10 2 Digital Enhanced Cordless Telecommunication (DECT) Digital Enhanced Cordless Telecommunications (Digital European Cordless Telecommunications), commonly known as DECT, is a digital wireless communication standard specified by European Telecommunications Standards Institute (ETSI). 2.1 DECT Network A DECT system includes Fixed Parts (FP) and Portable Parts (PP) DECT Fixed Part (FP) A Fixed Part may contain one or more Radio Fixed Parts (RFP) or Fixed Termination (FT), commonly known as the base station. Every RFP serves its own coverage cell. The area served by an FP is defined as a Location Area (LA) Portable Part (PP) A Portable Part is a grouping of both Portable Termination (PT) and Portable Application (PA). These two entities together are widely known as a Handset. Figure 2 DECT Reference model In essence, the DECT standard defines communication over the air interface between the PP and FP. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 10

11 2.2 DECT Protocol stack layers The protocol layers of DECT are completely bound to the lower three layers of the standard ISO Open Systems Interconnection (OSI) model. However, the layer 2 has been split into 2 sub layers, resulting in a 4 layered architecture. Figure 3 Figure 3: DECT Layers [ETSI ] The Medium Access Control (MAC) layer covers part of layer 1 and 2 of the OSI model. And the Lower Layer Management Entity (LLME) takes care of the management interface and common to all the layers of the DECT protocol stack. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 11

12 2.2.1 Physical Layer (PHL) Figure 4 DECT RF spectrum [DECT_FO] The Physical Layer divides the radio spectrum into physical channels. The division occurs both frequency and in time. In Europe, the frequency band from 1880 MHz to 1900 MHz is allocated for DECT. This 20 MHz is divided into 10 carriers in frequency domain. In time domain, each carrier is divided into 24 time slots for every 10ms span. The first 12 slots are used for uplink and the next 12 slots for downlink. Thus the full duplex communication is achieved by Multicarrier/ Time Division Multiple Access (TDMA)/ Time Division Duplex (TDD) approach Medium Access Control Layer (MAC) The MAC layer is responsible for the selection and connection handling of the physical channels. In addition to that it also multiplexes and demultiplexes control information, together with higher layer information and error control information, into slot-sized packets Data Link Control Layer (DLC) The DLC layer is responsible for reliable data transmission to the upper Network Layer. The DLC layer works closely with the MAC layer to provide the reliability. The separation of the stack into Control plane and User plane is introduced in DLC layer. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 12

13 2.2.4 Network Layer (NWK) The Network Layer controls the connection and signalling between the FT and PT. The NWK layer operates using an exchange of messages between peer entities. The NWK messages support the establishment, maintenance and release of calls. Additionally there are messages to support a range of other operations like mobility management. 2.3 DECT Protocol stack Planes The DECT protocol stack is further separated into two planes namely Control plane(c-plane) and a User Plane (U-plane). The C-plane is the interface to the control entity in the application, while the U-plane is designed for transport of data Control Plane The Control Plane is the control interface for the handset and base system. Through this interface the network layer services can be used to set-up calls and exchange end-to-end control information. The C-plane is also used by an interworking unit if the DECT system is to be connected to an external network User Plane The User Plane is the data interface between the handset and base system. In telephony applications U- plane is used to transfer ADPCM encoded voice data. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 13

14 2.4 DECT Identities Figure 5 Identity Structure [ETSI300175_6] DECT identities and special authentication algorithms ensure avoiding any security threat to the DECT system. Thus both the FP and PP have their own identities and authentication methods to find the authenticity of their counter parts FP Identities FP identities are used to inform PPs about the identity of a DECT FP and the access rights to that DECT FP and thereby reduce the number of access attempts from unauthorized portables. Using its Primary Access Rights Identifier (PARI) and Radio Fixed Part Number (RPN) the MAC layer of the FP generates and transmits a unique identity Radio Fixed Part Identity (RFPI) on a Simplex Bearer, also known as, a dummy bearer. Access Rights Class (ARC) and Access Rights Details (ARD) are the heart of the identity structure. ARC: Shows the type of access to a DECT network, such as public, private or residential. ARD: This number is unique to the service provider or to the equipment (e.g. in the case of residential and business applications this number is assigned by the manufacturer). Its structure depends on the ARC. The ARC and ARD form the ARI which is unique to a provider. The ARIs are classified into three categories. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 14

15 PARI: It is necessary to broadcast Primary ARI. This is the most frequently broadcasted ARI SARI: Secondary ARI. SARIs are less frequently broadcast than PARI. TARI: Tertiary ARI. The TARI is not broadcast at all and is only available as a (or in a) "TARI reply" message, which is an answer to a "TARI request" message including the relevant PARK{y}. Radio Fixed Part Identity (RFPI) An ARI together with a RPN forms the RFPI. The ARI embedded in the RFPI is the PARI. The RFPI serves three purposes. They carry the PARI Uniquely identify RFPs geographically Show domains for handover and location areas Figure 6 RFPI structure [ETSI300175_6] E RPN - This field indicates if there are any SARIs available. Value yes or no. - Radio fixed Part Number used for geographical separation PP Identities PP Identities enable a PP to select a valid FP and enable the FP to uniquely identify the PP within that FP Portable Access Rights Key (PARK) Portable Access Rights Key (PARK) and International Portable User Identity (IPUI) are the two main identities of a PP. The difference between the PARK and ARI is that PARK can have many ARDs associated with it. PARK is usually denoted as PARK{y} where the 'y' denotes the PARK length indicator (PLI) Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 15

16 Figure 7 PARK{y} structure [ETSI300175_6] There are four categories of PARKs, depending on the size of the DECT system: PARK Category A is the access right to small single- or multicell systems in private households. PARK Category B is the access right to more complex private branch exchanges and local area networks (LANs). PARK Category C is reserved for the public version of categories A and B. PARK Category D is designated for public use when a DECT system is connected directly to GSM International Portable User Identity (IPUI) An IPUI contains the Portable User Type (PUT) and the Portable User Number (PUN). A PUT is 4 bits long; the length of a PUN depends on the type of IPUI. For example, seven different types of IPUI for use in different applications are defined in DECT. IPUI Type N is the simplest type of IPUI. It consists of 4 bits long PUT and a 36-bit long PUN and is used in conjunction with PARK Class A in private households. This is globally unique and is available in every PP. This identity maybe used for emergency calls. IPUI Type S is provided for DECT connection to the ISDN because the 60-bit long PUN is coded like a PSTN or an ISDN number. It is used together with PARK Category A. IPUI Type O is a local unique number in a private branch exchange (PABX or LAN) based on PARK Category B. The PUN can be specified by the operator of the branch exchange so that it is a locally unique number corresponding to the PSTN number. The PUN is 60 bits in length. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 16

17 Figure 8 IPUI - Type N [ETSI300175_6] IPUI Type T is used for expanded branch exchanges. The 60-bit long PUN consists of a 16-bit long Equipment Installer's Code (EIC) and the additional number (44 bits). Large companies with a network of subsidiaries have the possibility of assigning each location with its own EIC. This enables each mobile station within the subsidiaries to be used just as it would be in the home subsidiary. IPUI Type P is globally unique and is intended to be used in 1 way or 2 way public access services or local loop applications. The 96-bit PUN consists of a Public Operator Code (POC, 16 bits) and an Account Number (ACC, 80 bits). The operator is coded in the POC. The uniqueness of the IPUI is only guaranteed through the POC and the ACC. IPUI Type Q Globally unique and similar to Type P, except for that subscribers will be charged via their bank accounts. IPUI type U This identity shall be globally unique and similar to IPUI P, except for that subscribers will be charged via their credit card accounts. IPUI type R This identity shall be globally unique and shall contain an IMSI to access GSM from DECT system Temporary Portable User Identity (TPUI) In local applications a temporary telephone number (Temporary Portable User Identity, TPUI) agreed between FP and PP is used for contacting a mobile station. This protects the IPUI, which in this case is not transmitted. The TPUI consists of 20 bits and is either the last part of an IPUI or an assigned TPUI. 2.5 MAC Identities Fixed MAC identity (FMID) FMID is the 12 least significant bits of the RFPI. It is the same for all the bearers of an FP if synchronization is supported between FPs, it is the same for all of them. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 17

18 2.5.2 Portable MAC identity (PMID) PMID is used to uniquely identify an active PP within the FP. It consists of 20 bits. It can have a default value, an assigned value or an emergency value. 2.6 Network Layer The Network layer (NWL) controls the connections between the handset (Portable Part, PP) and the base station (Fixed Part, FP). The C-plane carries out signalling, and is responsible for controlling data exchange. The U-plane in DECT has no tasks in the network layer, and forwards all data unprocessed in the vertical direction. There are five functional groups under Network layer: CC Call Control entity is the entity used for establishing, managing and releasing connections. CISS Call Independent Supplementary Service is a supplementary service that sets up and releases callindependent connections for supplementary services. COMS Connection-Oriented Message Service is a service that transmits packets between two end points. Thus supporting connection oriented service. CLMS Connectionless Message Service is a connectionless data service. MM Mobility Management is responsible for all tasks required for the mobility of mobile stations. It processes authentication messages and encryption data relating to the location area. LCE Link Control Entity Messages provides logical connections over which all of the above entities exchange messages. This entity has the responsibility to establish, manage and release C-plane link between the fixed termination and all the active portable terminations Mobility Management This service manages the functions of user identity, authentication and location area updating. All the messages needed for mobility management (MM) are discussed below. Identity Messages TEMPORARY_IDENTITY_ASSIGN TEMPORARY_IDENTITY_ASSIGN_ACK TEMPORARY_IDENTITY_ASSIGN_REJECT IDENTITY_REQUEST IDENTITY_REPLY Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 18

19 These messages can be used to query the FP about specific identification data of the PP and to assign a Temporary Portable User Identity (TPUI). The identification is always initiated by the FP. A TEMPORARY_IDENTITY_ASSIGN is sent by the FP to the PP to indicate a TPUI value to the PP. After that, the PP acknowledges the assignment with TEMPORARY_IDENTITY_ASSIGN_ACK. If the procedure was not successful the PP sends a TEMPORARY_IDENTITY_ASSIGN_REJECT with a reject reason. If the FP uses IDENTITY_REQUEST to request an identity from the PT, to which the PT responds with an IDENTITY_REPLY. Authentication Messages AUTHENTICATION_REQUEST AUTHENTICATION_REPLY AUTHENTICATION_REJECT Both FP and PP uses authentication messages to guarantee that both the devices has authorization. A new authentication key can be provided at the same time. The procedure is initiated with an AUTHENTICATION_REQUEST message. The calculated reply is returned with AUTHENTICATION_REPLY. If the authentication has not succeeded or another error occurs, the partner entity is informed through AUTHENTICATION_REJECT, and is able to take the appropriate action. Location Messages LOCATE_REQUEST LOCATE_ACCEPT LOCATE_REJECT DETACH These messages inform the network of the current location area of a PP. This enables an incoming call to be forwarded quickly to the respective PT. The mobile station sends a LOCATE_REQUEST message to the FP in order to establish a connection or to request a handover to another base station. The FP responds to a successful connection or handover with LOCATE_ACCEPT, and to an error with LOCATE_REJECT. If a mobile station is switched off, it informs the network with a Detach message. Access Rights Messages ACCESS_RIGHTS_REQUEST ACCESS_RIGHTS_TERMINATE_REQUEST Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 19

20 ACCESS_RIGHTS_ACCEPT ACCESS_RIGHTS_TERMINATE_ACCEPT ACCESS_RIGHTS_REJECT ACCESS_RIGHTS_TERMINATE_REJECT With these messages the International Portable User Identity (IPUI) and the Portable Access Rights Key (PARK) can be stored or cleared again in the PP. There are the four PARK classes A to D. An ACCESS_RIGHTS_REQUEST is sent by the PP to the FP to start the procedure. The FP responds with ACCESS_RIGHTS_ACCEPT and the corresponding parameters or with ACCESS_RIGHTS_REJECT if there has been an error and the requested parameters cannot be transmitted. Key Allocation Messages KEY_ALLOCATE This message is used to replace an authentication key (AC) with a user authentication key (UAC). Parameter Retrieval Messages MM_INFO_SUGGEST MM_INFO_REQUEST MM_INFO_ACCEPT MM_INFO_REJECT These messages supply information, e.g., for external handovers, which is transmitted with the help of existing connections. Using MM_INFO_SUGGEST, the FP can propose to a PP that it carry out a handover or location update. The PP uses MM_INFO_REQUEST to request information from the FP. The FP supplies this information sending an MM_INFO_ACCEPT message. If the information requested by the PP cannot be sent, the FP informs the PP accordingly with MM_INFO_REJECT. Ciphering Messages CIPHER_SUGGEST CIPHER_REQUEST CIPHER_REJECT Ciphering messages are used to transmit the ciphering parameters and to initiate or terminate the ciphering. The PP can make this recommendation to the FP with Cipher Suggest. This then takes place Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 20

21 through a Cipher Request from the FP to the PP. In the event that the PP is unable to carry out the ciphering, it responds accordingly with Cipher Reject Call Control (CC) Call control is an instance of an entity responsible for call handling. It is used to set up, maintain and release calls. Call Establishment Messages CC_SETUP CC_SETUP_ACK CC_INFO CC_CALL_PROC CC_ALERTING CC_NOTIFY CC_CONNECT CC_CONNECT_ACK CC_SETUP commences the call setup of call control, and can be initiated by both sides (FP and PP). Some of the setup parameters are sent at the same time; the other data is transmitted with CC Info. The CC_SETUP_ACK message is optional and is only sent in the direction of a mobile station. The CC_ALERTING message indicates to the network that the mobile station is calling or to the mobile station that the user terminal being called is being paged. CC_CONNECT signals the connection to the partner layer of the U-plane and CC_CONNECT_ACK acknowledges it. CC_NOTIFY is a message that can be sent during an existing connection in order to convey a message. Call Information Phase Messages CC_INFO CC_SERVICE_CHANGE CC_SERVICE_ACCEPT CC_SERVICE_REJECT IWU_INFO Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 21

22 CC_INFO message can be used to establish an end-to-end connection for the exchange of information. With CC_SERVICE_CHANGE the communication parameters can be changed during the setup phase or during the active phase. The CC_SERVICE_ACCEPT message constitutes the corresponding acknowledgement and a CC_SERVICE_REJECT message a rejection of the parameter changes. IWU_INFO is used to transport IWU Packet Elements or IWU to IWU Elements. Call-Related Supplementary Services FACILITY_HOLD HOLD_ACK HOLD_REJECT RETRIEVE RETRIEVE_ACK RETRIEVE_REJECT Call Release Messages CC_RELEASE CC_INFO CC_RELEASE_COM CC_RELEASE releases the call in the network layer. CC_RELEASE_COM is the acknowledgement for the release of the call Call Independent Supplementary Services (CISS) CISS_REGISTER FACILITY CISS_RELEASE_COM Supplementary services consist of call-independent supplementary services (CISS) and call-related supplementary services (CRSS). CISS connections are call-independent Connection-Oriented Message Service (COMS) COMS_SETUP COMS_NOTIFY Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 22

23 COMS_CONNECT COMS_INFO COMS_ACK COMS_RELEASE COMS_RELEASE_COM COMS offer a point-to-point connection that can be used for transmitting packets. This connection can be established at any time using COMS_SETUP. A successful connection is acknowledged with COMS_CONNECT. The connection phase uses a COMS Info message to transmit the information of a COMS connection. A COMS_ACK message acknowledges that one or more COMS_INFO messages have been correctly received. The COMS connection is released through a COMS_RELEASE command and acknowledged through COMS_RELEASE_COM Connectionless Message Services (CLMS) CLMS_VARIABLE CLMS_FIXED CLMS provides a connectionless point-to-point or point-to-multipoint service Link Control Entity Messages (LCE) LCE Establishment Messages LCE_REQUEST_PAGE LCE_PAGE_RESPONSE LCE_PAGE_REJECT The LCE entity in the physical layer is below the five entities (MM, CC, CISS, COMS, and CLMS) above it, and is used to set up connections to the partner layer with LCE_REQUEST_PAGE. The positive response to a connection setup request is LCE_PAGE_RESPONSE. The negative one is LCE_PAGE_REJECT. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 23

24 2.7 DECT call flow The following figure shows the DECT call flow model between two handsets within the same FP. PP1 FP PP2 (1) CC SETUP (2) CC SETUP ACK (3) CC INFO <<Multi keypad>> (4)CC SETUP (6)CC ALERTING (8) CC CONNECT DATA (5)CC ALERTING (7) CC CONNECT (9) CC CONNECT ACK DATA (10) CC RELEASE (11) CC RELEASE COM (12) CC RELEASE (13) CC RELEASE COM Figure 9 DECT call flow Communication Oriented messages are not taken into account to simplify the call flow. DECT outgoing call starts with the CC-SETUP from PP1. FP would respond with CC-SETUP-ACK, after which the PP1 would send the callee information with one or more CC-INFO messages. Once this information is received the FP would send a CC-SETUP to PP2. As the PP2 rings, it transmits CC-RINGING message to the FP. PP1 is informed of the CC-RINGING message. Once the user at PP2 picks up the call it sends the CC-CONNECT message to the FP, then the FP sends a CC-CONNECT to PP1 and it is now ready to receive data. FP sends CC-CONNECT-ACK to PP2 then the connection is established between PP1 and PP2. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 24

25 During call release, one of the handsets may choose to terminate the call by sending CC-RELEASE message to the FP. The FP will acknowledge with CC-RELEASE-COM message and it also releases the other end from the call by sending a CC-RELEASE message. 2.8 Handover mechanism in DECT network Unlike in other wireless standards like GSM, in DECT the handover is initiated by the handset. Although the FP can suggest handover, a handover request is always made by the handset. There are three types of DECT handovers. Bearer handover Connection handover External handover Bearer handover is intra cell handover, meaning it is within the same FP. For example, the PP may choose to use another slot in the current FP. Connection handover is carried out by changing one MAC connection to other. Both C-plane and U-plane information are completely transferred to the new MAC connection. Connection handover can happen between different RFPs but within the same FP. External handover happens in the NWK layer. It can also happen between different FP that are synchronized and share a common handover reference. We will discuss about external handover in detail. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 25

26 2.8.1 External handover The handset can make the handover decision by assessing two parameters. Signal strength of the current channel (RSSI) C/I ratio (CIR) of the channel RSSI and CRC are being measured at the handset using the periodic Nt messages broadcasted in the dummy bearer. When the handset detects that either the signal strength or the channel quality is degrading it decides to make a handover. When the signal strength degradation is detected a change in cell is desired. In order to support external handover, FP shall include an <<external h/o indicator>> with the CC-SETUP, CC-SETUP-ACK, CC-CONNECT, CC-INFO or MM-INFO-SUGGEST message. It also includes a <<network parameter>> element to facilitate the other FPs to identify the handover from within the network. Figure 10 DECT External handover To initiate external handover the PP sends an MM-INFO-REQUEST message with an <<info type>> information element indicating "external handover parameters". The FP should respond with an {MM- Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 26

27 INFO-ACCEPT} containing <<info type>> and one or more <<fixed identity>> information elements containing ARIs or PARKs to identify the FPs to which external handover may be attempted. Then the PP compares the PARI of the FP in use with the PARIs of the available FPs. If a PARI matches in the bits indicated by the <<ext h/o indicator>> information element s length indicator field, the PP selects that FP as a candidate FP. The PP then sends the CC-SETUP message to the FP2, with <<BASIC-SERVICE>> containing <Call class> field mentioning External Handover call setup and also the <<network parameter>> received from the current FP (FP1). Once the FP2 is sure that the handover request is authentic, it sends CC-CONNECT message. After the data connection is established, the PP may send CC-RELEASE to FP1 to disconnect the channels that has been used by the PP. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 27

28 3 Session Initiation Protocol (SIP) This chapter gives an overview of the Session Initiation Protocol and its techniques. For more details [RFC3261] can be referred. 3.1 Introduction SIP is a text based application layer protocol like HTTP. It was originally designed by Henning Schulzrinne and Mark Handley in It is developed by Internet Engineering Task Force (IETF) and the latest SIP specification is RFC3261, which was published in June Addressing SIP users are identified by a Uniform Resource Identifier called a SIP URI. SIP URI usually takes the form of an address. These SIP URIs are globally unique identities. The following are examples of valid SIP URIs: sip:bob@company.com sip:ben.linus@domain.com The above identifiers are also called as Address of Record (AOR) or more commonly Public URIs. SIP also supports user mobility, in the sense that user can be reached with his pubic URI irrespective of his present location. Registrars are used to achieve this feature. 3.3 Requests There are six basic Request methods: REGISTER - for registering contact information with the Registrar/ Location Service INVITE, ACK & CANCEL - these three methods are used for setting up sessions BYE - used for terminating sessions OPTIONS - for querying servers and UAS about their capabilities In addition to the above, there are extensions to support additional features in SIP REFER SUBSCRIBE/ NOTIFY UPDATE MESSAGE - used to support Call transfer facility - used to invoke presence Information - used to modify the session information without changing the session state - used for sending instant messages Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 28

29 Method Function Reference REGISTER Registers a user s address with his address of record. RFC3261 Same method is used to unregister an user INVITE This method is used to establish a call. It also includes RFC3261 SDP body with the SIP headers ACK ACK method is used to confirm a session request by RFC3261 INVITE method CANCEL The INVITE can be cancelled if the session is not yet RFC 3261 established BYE It can be used to tear down an already established, RFC3261 ongoing session OPTIONS This is used to query the other servers and UAs about RFC3261 their capabilities and the methods they support REFER This is mainly used for call transfer. The transfer can be attended or unattended. RFC3515, RFC 3892, RFC4488 SUBSCRIBE, NOTIFY SUBSCRIBE and NOTIFY methods are used to publish RFC3265 the presence information or the message notifications etc., UPDATE Similar to INVITE method. UPDATE can change the RFC 3311 session information without changing the session state. MESSAGE This extension is used to send instant messages RFC 3428 between the user agents. Table 1 SIP Request methods SIP REGISTER method SIP REGISTER message is used to create bindings of contact address and the permanent AOR. A sample REGISTER message is given below: REGISTER sip:proxya.com SIP/2.0 Via: SIP/2.0/udp :5061;branch=z9hG4bKnashds7 Max-Forwards: 70 From: usera <sip:usera@proxya.com>;tag=a73kszlfl To: usera <sip:usera@proxya.com> Call-ID: 8jfi94urd@proxyA.com CSeq: 1 REGISTER Expires: 3600 Contact: <sip:usera@ > Content-Length: 0 Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 29

30 REGISTER message is sent to user agent s proxy server. From and To headers both mention the AOR of the registering user. The message also carries the contact address of the usera in the Contact header. This information will be stored at the registrar. Another important header in the REGISTER message is the Expires: header. It holds the time in seconds indicating how long the registration is valid. After this time the binding at the registrar will be removed. The same REGISTER method is used to UNREGISTER a user as well. The only field that is changed is the Expires field. In order to UNREGISTER, Expires: is simply set to 0 (Expires: 0) and the REGISTER message is sent to the proxy server SIP INVITE method SIP INVITE method is used to establish a new session. When a user agent client wants to establish a session with another UE, it generates the INIVITE message addressed to that UE. A sample INVITE message is given below: (1)INVITE sip:userb@proxyb.com SIP/2.0 Via: SIP/2.0/UDP usera@proxya.com:5060;branch=z9hg4bk78c84 Max-Forwards: 70 Route: <sip:proxya.com> From: usera <usera@proxya.com>;tag=9kgx7tuvc To: usera <userb@proxyb.com> Call-ID: 765tyfjh8kl@proxyA.com CSeq: 1 INVITE (2)Contact: <sip:usera@ ;transport=udp> Content-Type: application/sdp Content-Length: 151 v=0 o=usera IN IP s=- (3)c=IN IP t=0 0 (4)m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 In (1) it is shown that the INVITE is addressed to the destination URI. In the From header the UAC places its AOR. To header carries the AOR of the destination. In (2) the Contact header, the originating UAC places its contact address. Content-Type shows that the message carried in the body of the message is SDP and its length is mentioned in Content-Length header. (3) Shows the c field in the sdp body that has the IP address of the originating user. This is the ip address where the media information shall be expected at usera. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 30

31 In (4) the m field shows the port number where one can deliver the data for that INVITE originator. In this message it is shown that usera will be listening to port number for audio data. 3.4 Responses SIP uses 3 digit response codes. The first digit gives the information about the response category of the message. There are six categories of responses defined. Provisional (1xx) - The message has been received and relevant action is being taken at the receiving side. ex: 100 Trying, 180 Ringing Success (2xx) -Request received, understood and completed successfully. ex: 200 OK Redirection (3xx) -Request cannot be fulfilled. So the sender needs to take appropriate action. ex: 302 Moved Temporarily Client Error (4xx ) - the request contains bad syntax or cannot be fulfilled at this server ex: 403 Forbidden, 404 Not found Server Error (5xx) -server failure. The server failed to fulfill an apparently valid request ex: 503 Service unavailable Global Failure (6xx) - the request cannot be fulfilled at any server ex: 603 Decline 3.5 SIP components There are several components that are involved in a typical SIP session. A very basic session can be carried out by using only two SIP telephony end points. But in practice there are more than just two end points involved in a SIP session. The SIP standard defines the following logical components: User agents Registrar Redirect servers Proxy servers User Agent SIP user agent is a basic component in a sip network which is able to initiate request and receive them as well. The part of the user agent that initiates the SIP requests and responding to the replies received for the request is called as User Agent Client (UAC) and the part that receives a SIP request made by the other end, process it and replies to that request, is known as User Agent Server (UAS) Registrar We discussed that every SIP user is identified by a globally unique AOR. But to provide mobility, these AORs are temporarily bound to the current contact URI address of the user. It is the SIP Registrar that Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 31

32 stores these bindings between the AOR and Contact address of a user. These Contact addresses of a SIP User are provided to the UACs upon valid requests. An AOR can be associated with many contact addresses at the same time. There is no limit to the number of concurrent contact addresses Redirect server A redirect server carries out a very simple task. It receives an incoming request and simply suggests the requestor to contact some other destination. This can be useful when a user has been moved to a new Proxy server Proxy servers make the routing decisions. When a proxy server receives a request, it makes decision based on the domain name of the destination URI. If the URI is within its domain, it may consult the registrar to find the current contact of the end point. In other cases, it will make the best decision based on the implemented logic. In real life, these logical components may also be integrated into the same entity. For example Proxy server and registrar may be incorporated to achieve best results. 3.6 Call Flow The first step is to register the handsets. User equipments must be registered for the other devices to find their location. As per our example, usera sends REGISTER message to its proxy server sip:proxya.com. If the authentication challenge is successful, proxya sends back OK message to the usera. And userb also goes through the same process. Now both the UEs are registered. Then usera INVITEs userb for a SIP session. The INVITE is addressed to sip:userb@proxyb.com and sent to sip:proxya.com. Proxy A checks the INVITE and routes the message towards proxyb.com and sends back a TRYING informational response to confirm that it has processed the request. Finally when the proxyb receives the INVITE message, it checks the destination address and finds that the message is for its domain. Then it consults with its registrar providing the AOR given in the INVITE. Since userb already registered, the registrar holds the current address of userb. Then the message is correctly routed to the current contact address of userb. When the userb s UE rings, its UAC sends the RINGING message to usera. When the call is answered by the end user at userb, it sends a 200 OK message. Both RINGING and OK messages contain the contact address of userb. So usera knows the location of userb by now. Thus it sends the ACK message to userb addressing its contact address. Once the ACK is received at the other end, the data transfer begins. When one of the users wants to terminate the session his user agent client sends a BYE message. The other end should acknowledge it with an OK message. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 32

33 Figure 11 SIP call flow Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 33

34 4 Overview of existing Multicell DECT-SIP interworking architecture An IWU translates the messages that are passed between two different interfaces in a way that can be understood by the target system. The DECT-SIP IWU converts the signals and messages used on the DECT air interface to a format suitable for SIP and vice versa., In this chapter the design of Aastra SIP DECT TM [ASTR_OM] solution is discussed. 4.1 Theoretical Analysis of the architecture Figure 12 Solution-1 Architecture [ASTR_OM] Aastra SIP DECT solution employs the use of a centralized mobility manager which stores the information about the RFPs and distributes this information to the other RFPs whenever necessary through a control interface. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 34

35 SIP Registrar/ Proxy SIP Phone Ethernet Open Mobility Manager OMM RFP RFP DECT Control signal SIP Data flow PP Figure 13 Solution 1 - Call flow [ASTR_OM] When the PP makes a call to the SIP phone, the current RFP of the PP contacts the OMM with the DECT message received from the PP. The OMM acts as an interworking unit and translates the DECT message to the appropriate SIP method and sends it to the SIP proxy. The SIP proxy would then contact the corresponding end point after consulting with the SIP registrar. After receiving the INVITE for a session the SIP phone contacts the RFP that requested for a session directly. So the data flow is between the SIP phone and the RFP. The OMM is not involved in the data transfer. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 35

36 Figure 14 Solution-1 handover [ASTR_OM] Figure 13 explains a handover between RFPs. A call is established through the primary RFP as described in the same way as explained above. All the DECT control information is handled by the OMM and it acts as translator between RFP and the SIP proxy. But finally the data transfer is directly between the SIP phone and the primary RFP. Now if the PP moves from once cell to another, it requests for a handover. Here the secondary RFP would then requests the OMM to hand over the call to it. Then the primary RFP is instructed to pass the media information to the secondary RFP. So the primary RFP routes the media information to the secondary RFP. But the SIP phone is not aware of this. It continues to send the data to the primary RFP. Thus the primary RFP stays in the loop for both signalling and data transfer. So we understand that using a manager interface between the DECT system and SIP system is a possible solution. But it requires an additional resource to act as a management entity above the whole DECT network. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 36

37 Using such a management entity gives rise to the following issues: The management entity can be overloaded with many requests Backup management entity is needed to provide load balancing and to avoid system failure. If the manager interfaces fail the whole system is down. Thus a new architecture is required to avoid using a management entity. So a new architecture is proposed and discussed in the following chapter. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 37

38 5 Proposal of an advanced architecture for DECT-SIP IWU From the previous chapter the following architecture is designed to work without the need for such an interface. 5.1 System Architecture Figure 15 System Architecture The architecture shown in Figure 15 chooses to equip every FP with an IWU, So that all the FPs in the network can connect with the SIP server directly. This eliminates the need for a manager entity which acts as an intermediate interface between DECT and SIP. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 38

39 The following figure shows the protocol level architecture of the proposed design. Figure 16 Protocal level design The interworking unit works upon the network layer of the Fixed Parts (FP). Every FP has an IWU which works with the IP/ PBX. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 39

40 5.2 Identity Mapping The portable identity IPUI type N is a globally unique PP ID. To derive a globally unique SIP AOR this IPUI is used in its HEX form. So IPUI of 0x 018a3becda would result in the SIP URI as given below: Ex: IPUI: 0x018a3becda => sip:018a3becda@sipproxy.com 5.3 DECT SIP Message mapping This section provides the mapping between DECT and SIP signalling. DECT Network layer messages are mapped with the SIP transactions. Basic call flow examples are also presented with brief explanations of the techniques involved. More information on the DECT messages can be found in [ETSI ] Outgoing call From PP to SIP client The Portable Part sends a CC-SETUP message to the FP when it wants to initiate an outgoing call. Upon receiving this request FP will respond with a CC-SETUP-ACK message. After that the calling PP will send the information of the dialled number with the<<multi-keypad>> info of the CC-INFO message. Now the IWU will look into the mapping table with the received number string and choose the corresponding SIP URI. Then the IWU will initiate an INVITE request to the SIP proxy with the URI. After receiving the RINGING response from the SIP server, IWU will issue a CC-ALERTING message to the PP. After having sent the CC-CONNECT to the PP and when the PP is ready for the data transfer the IWU will issue an ACK transaction to the SIP server. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 40

41 PP CC SETUP CC SETUP ACK CC INFO <<Multi keypad>> CC ALERTING CC CONNECT FP/IWU INVITE 180 RINGING 200 OK ACK SIP PROXY DATA Figure 17 PP Initiated Outgoing Call Incoming call When the IWU receives the INVITE request from the SIP server, It will analyse the To: and From: header fields of the INVITE transaction. Then it will generate the <<CALLING-PARTY-NUMBER>> and will send the CC-SETUP message to the corresponding PP which is being called as per the INVITE message. After receiving the CC-ALERTING, the IWU will send the RINGING response to the SIP client. The successful connection is established and the server is informed by a 200 OK response when the IWU receives the CC-CONNECT message. SIP sends the ACK message when the client is ready for data transfer and the PP is informed of the same by CC-CONNECT-ACK. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 41

42 Figure 18 Incoming call to the PP PP Initiated Call termination If the PP has sent a CC-RELEASE message during a call the IWU should respond to the SIP network with a BYE message which is used by SIP to terminate a session. The IWU should also send a CC-RELEASE-COM message to the PP. The IWU will receive an OK response from SIP server in turn for the BYE message sent by the IWU. Figure 19 PP initiated Call termination Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 42

43 5.3.4 Remote client initiated Call termination Upon the receipt of a BYE message from the network during an active call, the IWU should send a CC-RELEASE message to the PP. The IWU must respond to the SIP server with a 200 OK message after the receipt of CC-RELEASE-COM from the PP. Figure 20 Remote client initiated Call termination Re-registration The issue in combining DECT location registration and SIP registration lies in the inherent nature of the DECT handset s mobility. After the initial registration, in SIP a client s presence is indicated by periodic registrations. The periodic registrations are required to let the SIP proxy server know about the availability of the UAC. The client may fail to re-register for many reasons and it can be: Due to a network failure between the client system and the registrar The client system is shut down or terminated without properly logging of the session So to handle such situations the SIP REGISTER method uses an expiry field to indicate the time in seconds, after which the registration is no longer valid. Thus the Proxy server knows from its registrar that the client cannot contacted even when it fails to properly unregister itself. On the other hand, in DECT a handset is not required to periodically indicate its availability to operate properly. A handset should only send a location update upon request by the FP or on changing the location area. Also the PP cannot indicate when it moves out of the serving area of an FP. Because it can only detect the change in LA after moving out of the old FP s serving area. This mismatch should be handled in some way to achieve the objective. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 43

44 Figure 21 Re-registration So to solve this issue of re-registration in our interworking system, the PP shall send periodic LOCATE- REQUEST messages, meaning it must support the mandatory requirement for Enhanced location registration as defined in [ETS300824]. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 44

45 SIP REGISTER expires value is set to n seconds. Time limit in <<DURATION>> IE in {LOCATE-ACCEPT} is set to n seconds as well. So the PP sends {LOCATION-REQUEST} every n seconds. 5.4 Roaming Scenario The SIP MESSAGE method can be used to carry out the Authentication key (K) transaction. In the given scenario, The PP is initially subscribed to FP1. The derived K is stored in the server. Then the PP moves to FP2. Since the PP is not in the FP2 subscription list, it requests the server for the K value to authenticate the PP. Once the K value is attained, it authenticates the PP and accepts the location request. After the subscription process, the FP1 registers the PP with the SIP server. It also sends a SIP MESSAGE method to the server which contains the encrypted IPUI and K in text form. The encryption algorithm that can be used is not discussed in this paper. It is left to the implementation to specify the encryption method. But every step must be taken in the process, so that it is not possible to hack the encrypted message. The received IPUI and K value pair is stored in the server. The PP moves from FP1 to FP2, it detects the change in LA, thus triggering a LOCATE-REQUEST, as explained in section It is required that the FP always requests a session key (KS) or the Authentication Key (K) for the PP from the Server, when the LOCATE-REQUEST is received from a PP which is not in its subscription list. When there is no K value available, the FP simply rejects the request from the PP. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 45

46 Figure 22 Pre-call mobility Once the FP2 receives a LOCATE-REQUEST from a handset which is not in the subscription list, it sends the SIP REGISTER message as usual. But it doesn t acknowledge the handsets subscription on the DECT part yet. To authenticate the PP, the FP2 sends a MESSAGE to the SIP server with the IPUI value and a null value to indicate the absence of K value. When the server encounters such a MESSAGE it should respond either with the IPUI and K value pair or with IPUI and a null in case the K value is not available. If the FP2 receives the K value for the PP it sends a LOCATE-ACCEPT message thus authenticating PP s request. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 46

47 Figure 23 Registration process during roaming As an example the (7) MESSAGE method sent by FP2 that in Figure 23 would look like this: MESSAGE sip:sipproxy.com SIP/2.0 Via: Max-Forwards: 70 From: To: sip:sipproxy.com Call-ID: CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 120 ipui;authentication key (Encrypted) 5.5 Handover scenario for DECT Connection Handover The DECT Connection handover (CHO) involves switching the MAC connection to a new RFP from the old RFP s MAC connection. CHO is controlled and managed by the DLC layer. In the following example, the PP is in a call with FP1. PP may initiate connection handover because of a poor QoS of the currently established connection. The LLME invokes a MAC_CON-req primitive with the Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 47

48 CHO flag, indicating that the connection is required for connection handover. If the connection request is successful, the requesting side will be informed with MAC_CON-cfm primitive and the destination side will be informed with MAC_CON-ind primitive. This MAC_CON-ind shall also contain CHO flag. Figure 24 Connection Handover call flow 1) when a MAC_CON-ind with CHO flag set is received at an FP, it looks for the IP address of the FP under which the PP is active using the PMID and IP association. Then its IWU sends a SUBSCRIBE message with its DECT sdp details to accommodate a DLC relay. 2) The FP1 must acknowledge this with its SDP details. 3) As it receives a MAC connection release from the PP, the FP1 sends a NOTIFY message with XML content indicating the IPUI and the destination contact address and port. The <note> element of the NOTIFY message XML body can be used to send user defined data in a string format. [RFC3863] 4) Once all the information is available, FP2 shall send a re-invite to the sip endpoint. RTP transfer starts after the acknowledgement from the other end. 5) The other end shall send a BYE message to terminate the SIP session with FP1. The above solution doesn t involve the PBX at all. However, it can only work when the FP2 has access to the mapping between the PMID and IP address of the FP that is serving the call. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 48

49 5.6 Handover scenario for DECT External Handover The following figure shows a possible handover scenario in the proposed architecture. The PP is in a call with the SIP phone through FP1. Then it moves towards the FP2 and detects degradation in the received signal strength of FP1.So It searches for a better signal and decides to fix on FP2. It requests FP1 for a handover to FP2. Then it sends a CC-SETUP to FP2 with external handover indication. FP2 has to promptly REGISTER the handset with the SIP Registrar. On receiving an intimation from the PP about the completed handover, FP1 sends a REFER message to the SIP client with which there is an on-going call. The other party would, in turn, send an INVITE message to FP2 thereby connecting the call. The interworking unit in the FP2 will start bridging the call with the DECT call with PP. Figure 25 Handover Mechanism All the messages that are involved to carry out a handover successfully are described below. The following figure shows a PP which is in a call with a SIP phone through FP1. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 49

50 The PP may initiate a handover upon detection of a weak link between the current FP and itself. In general Handover candidate information is required to make a handover in the DECT network. During CC-SETUP, CC-SETUP-ACK, CC-CONNECT, CC-INFO, LOCATE-ACCEPT or MM-INFO-SUGGEST the FP provides the PP with <<ext h/o indicator>>, which indicates if the identities of other FPs are available for a handover. The FP also sends a <<network parameter>> information element with a handover reference. If the FP sends an <<ext h/o indicator>> with an OID field set to zero, it means that handover is not allowed. To initiate the handover the PP sends an MM-INFO-REQUEST message with an <<info type>> information element indicating "external handover parameters". The FP should respond with an {MM- INFO-ACCEPT} containing <<info type>> and one or more <<fixed identity>> information elements containing ARIs or PARKs to identify the FPs to which external handover may be attempted. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 50

51 FP/ IWU 2 (3) CC SETUP PP (1) MM INFO REQUEST (2) MM INFO ACCEPT FP/ IWU 1 SIP Proxy IP: IP: IP: DATA RTP Handover Triggered SIP Phone <External Handover call setup> (5) CC CONNECT (6) CC CONNECT ACK (4) REGISTER sip:ipui@ (7) CC RELEASE (9) CC RELEASE COM (11) INVITE sip:ipui@ (12) OK (15) ACK (8) REFER Refer to: sip:ipui@sipproxy.com (10) INVITE sip:ipui@sipproxy.com (13) BYE (14) OK RTP DECT Messages SIP Messages Figure 26 External Handover Call flow There is no need for the handover reference retrieval procedure, if the FP indicates that no handover reference is require by sending the <<network parameter>> information element indicating "Handover reference not required". As an alternative to the handover retrieval procedure, as specified in [ETS102265] a common SARI can be assigned for the DECT cluster where handover must be supported and shall be broadcasted by the FP1. It solves both the problems of identifying the possible handover candidates and the need for handover reference. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 51

52 In the CC-SETUP message the PP shall mark the <Call class > field in the <<Basic service>> IE with External handover call setup [ETS300824]. So that the Visiting FP will know that the CC-SETUP received is for an external handover, not to initiate a new call. On receipt of CC-SETUP indicating an external handover, the FP will sip REGISTER the handset using its IPUI. The (4) REGISTER method may look like this: REGISTER sip:sipproxy.com SIP/2.0 Via: SIP/2.0/UDP :5060;branch= z9hg4bijkl Max-Forwards: 70 From: Handset1 <sip:ipui@sipproxy.com>;tag=abc345 To: Handset1 <sip:ipui@sipproxy.com> Call-ID: pqr59xy@sipproxy.com CSeq: 1 REGISTER Contact: <sip: ipui@ > Content-Length: 0 Then it sends a CC-CONNECT to the PP. Thus the registration information on the SIP registrar is refreshed and the PP is also indicated that the handover is accepted. Now the PP sends a CC-RELEASE to the FP1. The FP1 proceeds to send a REFER message to the SIP phone it has been connected. The REFER message will have the Refer-to header set to point the SIP URI of the PP that has initiated external handover. (Ex: Refer-To: sip:ipui@sipproxy.com; method=invite). The (8) REFER method may look like: REFER sip:phone@ SIP/2.0 Via: SIP/2.0/UDP ;branch= z9hg4bkaklm From: <sip:ipui@ >;tag=60234 To: <sip:phone@sipproxy.com>;tag=84583 Call-ID: pr578gc@sipproxy.com CSeq: 22 REFER Max-Forwards: 70 Refer-To:sip:ipui@sipproxy.com Contact:sip:ipui@ Content-Length: 0 To avoid the implicit subscription created by the REFER method, the header field Refer-Sub can be used with the value false [RFC4488]. In response to the REFER, the SIP phone initiates a (10)INVITE message to the mentioned SIP URI, with the same from tag, to tag and Call-id: INVITE sip: ipui@sipproxy.com SIP/2.0 Via: SIP/2.0/UDP :5060;branch= z9hg4bk1023 Max-Forwards: 70 From: <sip:ipui@ >;tag=60234 To: <sip:phone@sipproxy.com>;tag=84583 Call-ID: pr578gc@sipproxy.com Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 52

53 CSeq: 1 INVITE Contact: <sip: phone@ > Content-Type: application/sdp Content-Length: 151 v=0 o=phone IN IP s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 The proxy server shall forward the INVITE to the FP2, because it knows the current SIP contact address for the PP. But it replicates all the other information like the from tag, to tag and call id from the received INVITE message. The (11) INVITE created at the proxy may look like: INVITE sip:ipui@ SIP/2.0 Via: SIP/2.0/UDP sipproxy.com;branch= z9hg4bk1456 Via: SIP/2.0/UDP :5060;branch= z9hg4bk1023 Max-Forwards: 70 From: <sip:ipui@ >;tag=60234 To: <sip:phone@sipproxy.com>;tag=84583 Call-ID: pr578gc@sipproxy.com CSeq: 1 INVITE Contact: <sip: phone@ > Content-Type: application/sdp Content-Length: 151 v=0 o=phone IN IP s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 FP2 shall send a 200 OK response with SDP information to the SIP phone with the contact field pointing to its current IP address. SIP/ OK Via: SIP/2.0/UDP :5060;branch=a3htm8 From: <sip:ipui@ >;tag=60234 To: <sip:phone@sipproxy.com>;tag=84583 Call-ID: pr578gc@sipproxy.com CSeq: 1 INVITE Contact: <sip: ipui@ ;transport=udp> Content-Type: application/sdp Content-Length: 147 v=0 o=handset IN IP Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 53

54 s=c=in IP t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 The data transfer starts after receiving the ACK message from the SIP phone. This ACK message will carry the SIP contact address of the handset. ACK sip:ipui@ SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: <sip:ipui@ >;tag=60234 To: <sip:phone@sipproxy.com>;tag=84583 Call-ID: pr578gc@sipproxy.com CSeq: 1 ACK Content-Length: 0 Meanwhile when the SIP phone receives OK message from the new client, FP2, it shall send a BYE request to FP1 thereby terminating the session with FP1 and also the data transfer to it. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 54

55 6 Implementation of the proposed architecture In this master thesis, for the DECT side of the implementation Dosch and Amand s DECT stack is used. To decide the SIP stack in designing the IWU different sip stacks are considered. For our implementation the architecture proposed in Fig.15 is used. DA1251 evaluation board is used in place of a DECT RFP. 6.1 Finalizing the SIP stack The following SIP stacks are considered PJSIP SofiaSIP Asterisk PJSIP Advantages of PJSIP Portable Very small footprint Feature rich Comprehensive Documentation Sofia SIP Advantages of Sofia SIP Well documented High level APIs to build applications Cross platform Asterisk as a SIP client Though originally designed to serve as a soft PBX, asterisk is a candidate, since it already has a SIP channel driver implemented. So it is decided to reuse asterisk s sip channel to serve as a sip client over the other SIP stacks. Advantages of Asterisk are: Good community support Constantly updated SIP channel 6.2 Software tools used The following software tools are used to implement the proposed architecture. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 55

56 Asterisk IP/PBX MySQL Relational Database Management System CMBS host application CMBS target application 6.3 Asterisk A Private Branch Exchange (PBX) by definition is a system that connects the internal telephone extensions with each other and to one or more outside telephone lines (PSTN). Asterisk is an open source software implementation of such a PBX. [ASTERISK] [ASTERISK GUIDE] General Asterisk was developed by Mark Spencer in It is licensed under GNU General Public License version 2 (GPL 2.0). Asterisk is initially designed to run on Linux. It supports various protocols like IAX, SIP and H.323. It uses channel drivers to allow the external devices to connect with it Configuration Asterisk uses configuration files (.conf) to define routing rules and user authentication. The two important configuration files that are relevant to this thesis are: sip.conf extensions.conf sip.conf This file contains the configuration details for the sip clients. It has a [general] section which has the information common to all sip clients. Every sip client that is to be connected to Asterisk will have its own section. Some of the valid parameters in [general] section are: [bindaddr]: IP address to bind (listen). IP address of here makes the asterisk listen to all IP [context]: Default context to check in extensions.conf (Chapter 5.2.2) when no unique context is found in the client section definition in the sip.conf [port]: Default port of peer [register]: user[:secret[:authuser]]@host[:port][/extension] To register with a SIP peer, client or a server. Ex: register => client:1234@ /server All the clients have their own section in sip.conf. The section name carries the extension number assigned to the client. Some of the valid parameters in the client sections are as follows: Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 56

57 [context]: The context to be matched in the dial plan. [type]: Type of the client. It can take user (only outbound calls to asterisk), peer (receive calls from asterisk) or friend (both inbound and outbound). [username] or [defaultuser]: The user name used for digest authentication. Usually not set as the name of the device is the name of the section itself. [host]: setting this to dynamic allows the client to register itself from any ip. If a particular address is set asterisk will look for the client at that IP address. [secret]: shared secret between asterisk and client for authentication and registration extensions.conf This file is used to define the dial plan for every context and extensions. We saw that the sip.conf file features a parameter called [context] in the client definition and [general] section. The dial plan for every context mentioned in sip.conf has to be defined in extensions.conf. In addition to that, to increase readability and clarity of dial plan, contexts can be defined separately and then included in contexts of the clients. A dial plan operation is indicated by the following syntax exten => name, priority, application () Where, name is the extension number Priority indicates the number of the step for the particular extension application () denotes the dial plan application Asterisk software architecture This section briefly explains the asterisk software architecture. For more information Asterisk developer documentation can be referred [ASTDEV] Asterisk core Asterisk is a highly modular application. The core module doesn t implement any functionality. But this asterisk core module loads various shared object modules during runtime. They all carry out different functionalities Asterisk Channel Drivers An asterisk channel represents a connection between asterisk and a user equipment of particular technology. Ex: SIP, IAX2, etc., Asterisk channel drivers are modules which acts as an abstraction layer between the asterisk core and the specific technology. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 57

58 An incoming call to asterisk of a particular technology comes into the corresponding channel driver. The channel driver then connects with the core asterisk channel. An outgoing call from asterisk starts from the core asterisk channel which in turn shall call the corresponding channel driver. The channel driver is then responsible for making a technology specific outgoing call to the user s device. Figure 27 Asterisk generic channel - incoming call In Figure 26, an incoming call to asterisk is depicted. The channel driver requests the channel core to allocate an asterisk channel for the specific technology using ast_channel_alloc() function. It is up to the channel driver to provide all the details needed to asterisk core to make the channel of that type. Once the channel is initialized, the channel driver runs the dial plan, which is defined by the extensions.conf file by calling the ast_pbx_start ( ) function. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 58

59 The pbx thread invokes the Dial ( ) function which makes the asterisk core to request the channel driver of type mentioned in the Dial application to get a channel of that type allocated. Once the channel is initialized by the channel driver, the asterisk core calls the ast_call () call back function which in turn will call the technology specific outgoing call function implemented by the channel driver. sd Asterisk outgoing call: PBX thread Channel Core Channel Driver ast_pbx_start( ) Dial( ) ast_request( ) ast_chan_alloc() return channel channel_initialize( ) ast_call( ) Call device( ) Technology specific Figure 28 Asterisk - Generic channel outgoing call When both the channels answer the call, asterisk simply bridges both the call legs, thereby staying in the middle throughout the call. If both call legs involves the same technology, asterisk may also stay out of the data path, while still handling the control messages. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 59

60 6.4 Software Implementation For the test implementation of the interworking unit, Asterisk IP PABX is used with a DECT channel driver. A simplified block diagram is given below: Figure 29 Asterisk channel interaction Asterisk channel core act as an abstraction layer and interacts with the DECT channel driver and SIP channel driver. DECT channel driver is to be designed for our implementation. The complete software block diagram is given below: Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 60

61 Figure 30 Software block diagram The following are the main software modules in the implementation of the system: MySQL registry monitor DECT channel driver for asterisk MySQL registry monitor is responsible for SIP registering the DECT handsets with the remote Asterisk IP-PBX. DECT channel driver is the interface between the DECT base station s CMBS target API and Asterisk s SIP channel. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 61

62 6.4.1 Registry Monitor thread using MySQL API Figure 31 mysql thread for registration monitoring In our implementation we have used asterisk realtime to load and unload the user devices with the help of MySQL database. Both asterisk realtime and MySQL basics are covered in the Appendix section of this paper. Registry monitor thread serves two purposes Registering DECT Handsets to the remote Asterisk SIP PBX Removing expired registration information of a PP This thread takes care of registering the DECT handsets to the remote SIP registry. Whenever a LOCATE_REQUEST is received from a PP, it extracts the relevant information and invokes local Asterisk SIP client to send a register message to the Asterisk PBX. Thus letting it know the location of the particular handset. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 62

63 When a handset moves to a new location area, it doesn t intimate the current FP. So the monitor thread checks the registry periodically and removes any expired registrations, so as to avoid further registrations with the Asterisk SIP PBX. If not removed, the remote asterisk would be informed wrongly of the location of the PP DECT channel driver design Incoming call to asterisk The following figure shows the DECT incoming call to Asterisk from the DECT device (handset). Incoming call is received in the channel driver from CMBS host. When the channel driver receives a CC-SETUP message from CMBS host, it starts the channel allocation process in the channel core as explained in section All the other steps remain the same as described in section Figure 32 DECT incoming call Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 63

64 Outgoing call from asterisk When the Dial () function in the asterisk dial plan encounters technology type GAP, it starts the channel allocation process with the DECT channel driver. Once the channel allocation and initialization is complete, asterisk channel core executes ast_call () function. This call back function invokes the DECT call object in the DECT channel driver. Figure 33 DECT outgoing call Then the DECT channel driver sends CC-SETUP message trigger to the CMBS host, which would then communicate this information with CMBS target. After that the base station is requested to send a CC- SETUP to the appropriate handset by the CMBS target. Finally the call is received at the destination. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 64

65 7 Test set up The following tools are required for this set up: Dosch & Amand - DA Handset 1 (PP) 1 Linux PCs with Asterisk 2 SIP Phone Test Architecture The test architecture involves Linux PCs with asterisk running on them. Dosch & Amand s DA1251 module is connected with the PC through USB which would serve as a DECT FP. Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 65

66 Figure 34 Test setup Advanced Distributed DECT SIP Interworking Unit for Multicell Systems 66