DOCSLIB.ORG

Guidelines for IPX Provider Networks (Previously Inter- Service Provider IP Backbone Guidelines) Version 14.0 01 August 2018

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guidelines for IPX Provider Networks (Previously Inter- Service Provider IP Backbone Guidelines) Version 14.0 01 August 2018 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) Guidelines for IPX Provider networks (Previously Inter- Service Provider IP Backbone Guidelines) Version 14.0 01 August 2018 This is a Non-binding Permanent Reference Document of the GSMA Security Classification: Non-confidential Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted under the security classification without the prior written approval of the Association. Copyright Notice Copyright © 2018 GSM Association Disclaimer The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document. The information contained in this document may be subject to change without prior notice. Antitrust Notice The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. V14.0 Page 1 of 52 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) Table of Contents 1. Introduction 3 1.1 Overview 3 1.1.1 Purpose 3 1.1.2 Background 4 1.1.3 About this Document 4 1.2 Scope 5 1.2.1 In Scope 5 1.2.2 Out of Scope 5 1.3 Definition of Terms 5 1.4 Document Cross-References 7 2 The Need for IP Interconnect 8 2.1 General 8 2.2 IPX 9 3 IPX Network Architecture 10 3.1 IPX Network Connection 10 3.2 IPX Architecture 10 3.3 IPX Connectivity Options 11 3.3.1 IPX Transport 11 3.3.2 IPX Service Transit 12 3.3.3 IP Service Hub 12 3.4 IPX Proxy Services 12 3.5 Types of Service Provider and Interconnectivity Allowed 13 4 Requirements of the IPX Networks 13 4.1 General 13 4.2 Separation of IPX Services on IPX Networks 14 4.3 Number of IPX Providers used to Transit Packets between Service Providers 14 4.4 Connections between IPX Provider and Service Provider 14 4.5 IPX Provider Peering Interface 15 4.6 Technical Specification of the IPX Network 17 4.6.1 IP Routing 17 4.6.2 BGP-4 Advertisement Rules 18 4.6.3 IPX Service to VLAN/VPN Mapping and Advertisement 18 4.6.4 IP Addressing and Routing 20 4.6.5 DNS/ENUM 21 4.6.6 Security and Screening 21 4.6.7 QoS 21 4.6.8 Generic IPX Proxy Requirements 21 5 Technical Requirements for Service Providers 22 5.1 General Service Provider Requirements 22 5.1.1 Service Provider IP Routing 22 5.1.2 Service Provider IP Addressing 22 5.1.3 Service Provider DNS 23 5.1.4 Service Provider Security and Screening 23 V14.0 Page 1 of 52 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) 5.2 BGP Advertisement Rules 24 5.2.1 General Rules 24 5.3 Service Provider and IPX Network Connectivity 24 6 QoS 25 6.1 SLA for IPX Network 25 6.1.1 Service Guarantees 26 6.1.2 Responsibilities 26 6.2 Traffic classification 26 6.2.1 UMTS QoS parameters 26 6.2.2 EPS QoS Class Identifiers 27 6.2.3 Diffserv Per Hop Behaviour 27 6.2.4 IPX traffic classes 27 6.2.5 Differentiated Services Code Point 27 6.2.6 2G/3G and EPS traffic marking 27 6.2.7 Application traffic marking 28 6.2.8 Packet marking rules 29 6.3 IP QoS Definitions for IPX Network 30 6.3.1 Availability 30 6.3.2 Delay 31 6.3.3 Jitter 34 6.3.4 Packet Loss Rate 36 7 Traffic Applications 36 7.1 GPRS/3G/4G Data Roaming 36 7.2 Service Provider Bilateral Services 37 7.3 WLAN Roaming 37 7.4 MMS Interworking 38 7.5 IMS 38 Annex A Considerations for implementation 40 A.1 A.1 Double IPX Provider network problem 40 A.1.1 Short term solution: Network configuration 40 A.1.2 Short-term solution disadvantages 41 A.1.3 Long-term solution: Network design in Service Provider network 41 Annex B IPX Proxy Requirements 44 B.1 Introduction 44 B.2 Requirements for IPX Proxy 44 B.2.1 General 44 Annex C Document Management 49 C.1 Document History 49 Other Information 51 V14.0 Page 2 of 52 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) 1. Introduction 1.1 Overview 1.1.1 Purpose The internet Protocol (IP) Packet eXchange (IPX) Network is an inter-Service Provider IP backbone which comprises the interconnected networks of IPX Providers and General Packet Radio Service (GPRS) Roaming eXchange (GRX) Providers. The IPX network supports multiple IPX services. The purpose of this document is to provide guidelines and technical information on how these networks are set-up and interconnect, and how Service Providers will connect to the IPX Provider networks. The services supported on IPX are out of scope for this document and are currently listed in GSMA Permanent Reference Document (PRD) AA.51. An IPX service is a service that requires the IPX network for either isolation from the Internet and/or for quality of service and experience. See GSMA PRD AA.51 [27] for a list of IPX Services. Contrary to previous versions of IR.34, GRX is now considered an IPX service which is offered on an IPX Network. The term GRX network is no longer used; however, an entity which only offers the GRX service may refer to itself as a GRX Provider. IPX Provider IPX Provider network Peering for IPX services network including GRX IPX Network Peering for Peering for GRX service only GRX service only GRX Provider network Figure 1: IPX Network comprising interconnected networks of GRX and IPX providers The IP Packet eXchange (IPX) is thus a model which encompasses commercial, technical and operational requirements. The implementation of this model consists of a number of interconnected IP networks operated and managed by International Carriers and domestic Providers (IPX Providers) which compete for interconnecting Service Providers according to mutually beneficial business models. V14.0 Page 3 of 52 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) From a network perspective IPX is a global, private, multiservice, secure IP network, open to any Service Provider under a contractual agreement which supports end-to-end quality of service. From a commercial perspective, it supports the principle of cascading interconnect payments (when it applies), In order to provide these features, the IPX can be service aware, unlike the Internet and the GPRS Roaming eXchange (GRX) network. This document also defines high level security requirements for the Inter-Service Provider IP network. Detailed complementary requirements can be found in the PRD: “Inter-Operator IP backbone Security Requirements for Service Providers and Inter-operator IP Backbone Providers” IR.77 [19]. 1.1.2 Background The IPX Network was originally conceived as an inter-Service Provider IP backbone created to carry GTP-tunnels (GPRS Tunnelling Protocol) via the Gp interface between the GPRS Support Nodes (GSNs) in different GSM Operators that is, data roaming. The Gp interface allowed mobile end-users to make use of the GPRS/3G services of their home network while roaming in a visited network. Later, Multimedia Messaging Service (MMS) interworking and Wireless Local Area Network (WLAN) authentication data roaming were added as supported services. This original inter-Service Provider IP backbone is in fact an Inter-PLMN (Public Land Mobile Network) IP Backbone and was termed the GRX. The GRX model is used to interconnect hundreds of networks and has proven highly successful. With the subsequent development of IP-based services assisted by the spread of mobile and fixed broadband technologies, interworking of such services has become an industry wide challenge. The GRX model is applicable as an IP interworking solution; however, the GRX specification does not meet all the requirements. It has been recognised that by adding interworking specific functionality to the GRX model and offering it to the industry, a common interconnect platform could be established for IP interworking. The enhanced GRX network is called the IPX network and is designed to support a variety of types of Service Providers in a secure and business sustainable way. The core enhancements to the GRX are end-to-end Quality of Service and the introduction of the service awareness facilitates interconnect, cascaded billing and multi-lateral interconnect agreements. 1.1.3 About this Document The document provides a brief introduction to the requirements for IP interworking and the IPX network. The technical architectures of the IPX network are described followed by the technical implementation guidelines for IPX (and GRX) Providers and connecting Service Providers. Technical guidelines for Security, Quality of Service and Traffic applications are also given. Appendices provide details on known issues in the IPX Network and on the requirements for IPX proxies. V14.0 Page 4 of 52 GSM Association Non-confidential Official Document IR.34 - Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines) 1.2 Scope 1.2.1 In Scope IPX Network: an inter-Service Provider IP backbone network architecture which connects Mobile Network Operators (MNOs), Fixed Network Operators (FNOs) Internet Service Providers (ISPs), Application Service Providers (ASPs), On-Line Service Providers (OSPs) etc., from here on in referred to collectively as "Service Providers".
Load more

Recommended publications
  • Gs Mec 011 V1.1.1 (2017-07)
    ETSI GS MEC 011 V1.1.1 (2017-07) GROUP SPECIFICATION Mobile Edge Computing (MEC); Mobile Edge Platform Application Enablement Disclaimer The present document has been produced and approved by the Mobile Edge Computing (MEC) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. 2 ETSI GS MEC 011 V1.1.1 (2017-07) Reference DGS/MEC-0011Plat.App.Enablemen Keywords API, MEC ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • How to Find out the IP Address of an Omron
    Communications Middleware/Network Browser How to find an Omron Controller’s IP address Valin Corporation | www.valin.com Overview • Many Omron PLC’s have Ethernet ports or Ethernet port options • The IP address for a PLC is usually changed by the programmer • Most customers do not mark the controller with IP address (label etc.) • Very difficult to communicate to the PLC over Ethernet if the IP address is unknown. Valin Corporation | www.valin.com Simple Ethernet Network Basics IP address is up to 12 digits (4 octets) Ex:192.168.1.1 For MOST PLC programming applications, the first 3 octets are the network address and the last is the node address. In above example 192.168.1 is network address, 1 is node address. For devices to communicate on a simple network: • Every device IP Network address must be the same. • Every device node number must be different. Device Laptop EX: Omron PLC 192.168.1.1 192.168.1.1 Device Laptop EX: Omron PLC 127.27.250.5 192.168.1.1 Device Laptop EX: Omron PLC 192.168.1.3 192.168.1.1 Valin Corporation | www.valin.com Omron Default IP Address • Most Omron Ethernet devices use one of the following IP addresses by default. Omron PLC 192.168.250.1 OR 192.168.1.1 Valin Corporation | www.valin.com PING Command • PING is a way to check if the device is connected (both virtually and physically) to the network. • Windows Command Prompt command. • PC must use the same network number as device (See previous) • Example: “ping 172.21.90.5” will test to see if a device with that IP address is connected to the PC.
    [Show full text]
  • Xerox® Colorqube 8580/8880 Color Printer 3 System Administrator Guide
    Xerox® ColorQube® 8580 / 8880 Color Printer Imprimante couleur System Administrator Guide Guide de l’administrateur système © 2015 Xerox Corporation. All rights reserved. Unpublished rights reserved under the copyright laws of the United States. Contents of this publication may not be reproduced in any form without permission of Xerox Corporation. Copyright protection claimed includes all forms of matters of copyrightable materials and information now allowed by statutory or judicial law or hereinafter granted, including without limitation, material generated from the software programs which are displayed on the screen such as styles, templates, icons, screen displays, looks, and so on. Xerox® and Xerox and Design®, Phaser®, PhaserSMART®, PhaserMatch®, PhaserCal®, PhaserMeter™, CentreWare®, PagePack®, eClick®, PrintingScout®, Walk-Up®, WorkCentre®, FreeFlow®, SMARTsend®, Scan to PC Desktop®, MeterAssistant®, SuppliesAssistant®, Xerox Secure Access Unified ID System®, Xerox Extensible Interface Platform®, ColorQube®, Global Print Driver®, and Mobile Express Driver® are trademarks of Xerox Corporation in the United States and/or other countries. Adobe® Reader®, Adobe® Type Manager®, ATM™, Flash®, Macromedia®, Photoshop®, and PostScript® are trademarks of Adobe Systems Incorporated in the United States and/or other countries. Apple, Bonjour, EtherTalk, TrueType, iPad, iPhone, iPod, iPod touch, Mac and Mac OS are trademarks of Apple Inc., registered in the U.S. and other countries. AirPrint and the AirPrint logo are trademarks of Apple Inc. HP-GL®, HP-UX®, and PCL® are trademarks of Hewlett-Packard Corporation in the United States and/or other countries. IBM® and AIX® are trademarks of International Business Machines Corporation in the United States and/or other countries. Microsoft®, Windows Vista®, Windows®, and Windows Server® are trademarks of Microsoft Corporation in the United States and other countries.
    [Show full text]
  • Cs-204: Computer Networks
    CS-204: COMPUTER NETWORKS Lecture 5 Chapter 19- Network Layer: Logical Addressing Instructor: Dr. Vandana Kushwaha 1. INTRODUCTION Communication at the network layer is host-to-host (computer-to-computer); a computer somewhere in the world needs to communicate with another computer somewhere else in the world. Usually, computers communicate through the Internet. The packet transmitted by the sending computer may pass through several LANs or WANs before reaching the destination computer. For this level of communication, we need a global addressing scheme; we called this logical addressing or IP address. 2. IPv4 ADDRESSES An IPv4 address is a 32-bit address that uniquely and universally defines the connection of a device (for example, a computer or a router) to the Internet. IPv4 addresses are unique. They are unique in the sense that each address defines one, and only one, connection to the Internet. Two devices on the Internet can never have the same address at the same time. But by using some strategies, an address may be assigned to a device for a time period and then taken away and assigned to another device. On the other hand, if a device operating at the network layer has m connections to the Internet, it needs to have m addresses. A router is such a device which needs as many IP addresses as the number of ports are there in it. 2.1. Address Space A protocol such as IPv4 that defines addresses has an address space. An address space is the total number of addresses used by the protocol. If a protocol uses N bits to define an address, the address space is 2N because each bit can have two different values (0 or 1) and N bits can have 2N values.
    [Show full text]
  • Experimenting with Srv6: a Tunneling Protocol Supporting Network Slicing in 5G and Beyond
    This is a postprint version of the following published document: Gramaglia, M., et al. Experimenting with SRv6: a tunneling protocol supporting network slicing in 5G and beyond. In, 2020 IEEE 25th International Workshop on Computer Aided Modeling and Design of Communication Links and Networks (CAMAD), 14-16 September 2020 (Virtual Conference). IEEE, 2020, 6 Pp. DOI: https://doi.org/10.1109/CAMAD50429.2020.9209260 © 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Experimenting with SRv6: a Tunneling Protocol supporting Network Slicing in 5G and beyond Marco Gramaglia∗, Vincenzo Sciancalepore†, Francisco J. Fernandez-Maestro‡, Ramon Perez∗§, Pablo Serrano∗, Albert Banchs∗¶ ∗Universidad Carlos III de Madrid, Spain †NEC Laboratories Europe, Germany ‡Ericsson Spain §Telcaria Ideas, Spain ¶IMDEA Networks Institute, Spain Abstract—With network slicing, operators can acquire and Additionally, specific core network functions and procedures manage virtual instances of a mobile network, tailored to a have been introduced to correctly manage network slice life- given service, in this way maximizing flexibility while increasing cycle management operations, such as Network Slice Selection the overall resource utilization. However, the currently used tunnelling protocol, i.e., GTP, might not be the most appropriate Function (NSSF), Network Slice Selection Assistance Infor- choice for the envisioned scenarios, given its unawareness of mation (NSSAI), and so on.
    [Show full text]
  • Multitech Bluetooth Network Access Point Administrator Guide S000619 Rev 1.2 for Use with Model: MT200B2E
    MultiTech Bluetooth® Network Access Point Administrator Guide MultiTech Bluetooth Network Access Point Administrator Guide S000619 Rev 1.2 For use with model: MT200B2E Copyright This publication may not be reproduced, in whole or in part, without the specific and express prior written permission signed by an executive officer of Multi-Tech Systems, Inc. All rights reserved. Copyright © 2015 by Multi-Tech Systems, Inc. Multi-Tech Systems, Inc. makes no representations or warranties, whether express, implied or by estoppels, with respect to the content, information, material and recommendations herein and specifically disclaims any implied warranties of merchantability, fitness for any particular purpose and non- infringement. Multi-Tech Systems, Inc. reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Multi-Tech Systems, Inc. to notify any person or organization of such revisions or changes. Trademarks MultiTech, MultiConnect, and the MultiTech logo are registered trademarks of Multi-Tech Systems, Inc. Bluetooth is a registered trademark of Bluetooth SIG, Inc. All other brand and product names are trademarks or registered trademarks of their respective companies. Contacting MultiTech Knowledge Base The Knowledge Base provides immediate access to support information and resolutions for all MultiTech products. Visit http://www.multitech.com/kb.go. Support Portal To create an account and submit a support case directly to our technical support team, visit: https://support.multitech.com Support Business Hours: M-F, 9am to 5pm CT Country By Email By Phone Europe, Middle East, Africa: [email protected] +(44) 118 959 7774 U.S., Canada, all others: [email protected] (800) 972-2439 or (763) 717-5863 World Headquarters Multi-Tech Systems, Inc.
    [Show full text]
  • Release Notes Release 10.3.0.2 E98788-01
    Oracle® Communications Performance Intelligence Center Oracle Communications Performance Intelligence Center Release Notes Release 10.3.0.2 E98788-01 November 2019 Oracle® Communications Performance Intelligence Center Oracle Communications Performance Intelligence Center Release Notes, Release 10.3.0.2 Copyright © 2003, 2019 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notices are applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • INTRODUCTION to SUBNETTING How to Maximize Network Addresses
    Volume 1 • Issue 8 September–October 2000 Introduction to Industrial Ethernet, Part 5. Part 4 was featured in Issue 6, the MAY–JUNE 2000. If you would like a copy, please send your request to EXTENSION [email protected] A Technical Supplement to control NETWORK © 2000 Contemporary Control Systems, Inc. INTRODUCTION TO SUBNETTING How to maximize network addresses. By George Thomas, Contemporary Controls INTRODUCTION address to distinguish it from the Class Addressing other computers. With IP In a previous article we discussed addressing, servers and IPv4 is called a classful system the Internet Protocol and the workstations are all termed hosts under RFC 761 with IP addresses structure of IP addresses. An IP but each address not only identifies being defined as belonging to one address identifies the source and a host but the address of the of five classes A, B, C, D or E. destination of a directed or unicast network on which the host resides. Classes A, B and C define different possible combinations of network message and is defined in RFC 761. This is because IP is an and host addresses. Class D is IPv4 is the most common version internetworking protocol that not reserved for multicasting. of IP addressing requiring 32-bit only allows communication Multicasting is the ability of one addresses. Although IPv6, the 128- between hosts on the same host to communicate with many bit version, will be used in the network, but communication other hosts with one transmission future, this article will restrict the between hosts on different and is beyond the scope of this discussion to IPv4.
    [Show full text]
  • An Internet Protocol (IP) Address Is a Numerical Label That Is
    Computer Communication Networks Lecture No. 5 Computer Network Lectures IP address An Internet Protocol (IP) address is a numerical label that is assigned to devices participating in a computer network, that uses the Internet Protocol for communication between its nodes. An IP address serves two principal functions: 1- host or network interface identification 2- location addressing. Its role has been characterized as follows: "A name indicates what we seek. An address indicates where it is. A route indicates how to get there." The designers of TCP/IP defined an IP address as a 32-bit number and this system, known as Internet Protocol Version 4 or IPv4, is still in use today. However, due to the enormous growth of the Internet and the resulting depletion of available addresses, a new addressing system (IPv6), using 128 bits for the address, was developed in 1995. Although IP addresses are stored as binary numbers, they are usually displayed in human-readable notations, such as 208.77.188.166 (for IPv4), and 2001:db8:0:1234:0:567:1:1 (for IPv6). The Internet Protocol also routes data packets between networks; IP addresses specify the locations of the source and destination nodes in the topology of the routing system. For this purpose, some of the bits in an IP address are used to designate a sub network. As the development of private networks raised the threat of IPv4 address exhaustion, RFC 1918 set aside a group of private address spaces that may be used by anyone on private networks. They are often used with network address translators to connect to the global public Internet.
    [Show full text]
  • Development Guide
    DEVELOPMENT GUIDE FOR INDUSTRIAL USING NB-IoT ABOUT THE GSMA ABOUT THE GSMA INTERNET OF THINGS The GSMA represents the interests of mobile PROGRAMME operators worldwide, uniting more than 750 operators with over 350 companies in the broader The GSMA’s Internet of Things Programme is an mobile ecosystem, including handset and device industry initiative focused on: makers, software companies, equipment providers and internet companies, as well as organisations in COVERAGE of machine friendly, cost effective adjacent industry sectors. The GSMA also produces networks to deliver global and universal benefits industry-leading events such as Mobile World Congress, Mobile World Congress Shanghai, Mobile CAPABILITY to capture higher value services World Congress Americas and the Mobile 360 beyond connectivity, at scale Series of conferences. CYBERSECURITY to enable a trusted IoT where For more information, please visit the GSMA security is embedded from the beginning, at every corporate website at www.gsma.com. stage of the IoT value chainBy developing key enablers, facilitating industry collaboration and Follow the GSMA on Twitter: @GSMA. supporting network optimisation, the Internet of Things Programme is enabling consumers and businesses to harness a host of rich new services, connected by intelligent and secure mobile networks. Visit gsma.com/iot or follow gsma.at/iot to find out more about the GSMA IoT Programme. 02 DEVELOPMENT GUIDE FOR INDUSTRIAL USING NB-IOT Contents 1. Introduction 04 2. Examples of Industrial Applications 04 2.1. Smart Industrial Factory Monitoring 04 2.2. Industrial Goods Tracker 04 3. NB-IoT in the Industrial Application Lifecycle 05 3.1. Smart Industrial Factory Monitoring 08 3.2.
    [Show full text]
  • Security for the Core Network of Third Generation Mobile Systems
    Security for the core network of third generation mobile systems GUNTER HORN, DIRK KROSELBERG Siemens AG, Corporate Technology, D-81730 Muenchen, Germany STEFANPUTZ T-Mobil, P.O. Box 300463, D-53184 Bonn, Germany ROLAND SCHMITZ T-Nova Technology Centre, D-64307 Darmstadt, Germany Keywords: UMTS, MAP Security, Multimedia domain, SIP, IPSec, IKE, Key Management Abstract: This contribution gives a survey of the present standardisation activities by 3GPP (3'd Generation Partnership Project1) in the area of security for signalling in the core network of third generation mobile systems. We give an overview of the protocols that need to be secured, present the basic principles behind the overall security architecture and describe the key management and format of secured messages, as far as they have already been finalised. In particular, we address core network security aspects of the 3GPP multimedia domain. 1 3GPP was formed by regional standards organisations from Europe, Asia and North America to produce specifications for a third generation mobile system named UMTS which is designed to evolve from GSM core network. There is a competing effort known as 3GPP2 with partners from North America and Asia. The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35413-2_36 R. Steinmetz et al. (eds.), Communications and Multimedia Security Issues of the New Century © IFIP International Federation for Information Processing 2001 298 1. THREATS TO CORE NETWORK SECURITY FOR MOBILE RADIO NETWORKS The core network of mobile radio systems is the part of the network which is independent of the radio interface technology of the mobile terminal.
    [Show full text]
  • IP ADDRESS ASSIGNMENT in a MOBILE AD HOC NETWORK Mansoor Mohsin and Ravi Prakash the University of Texas at Dallas Richardson, TX
    MILCOM 2002 1 IP ADDRESS ASSIGNMENT IN A MOBILE AD HOC NETWORK Mansoor Mohsin and Ravi Prakash The University of Texas at Dallas Richardson, TX Abstract—A Mobile Ad Hoc Network (MANET) consists of a set of iden- proactive approach based on the binary split idea of [5] [6]. tical mobile nodes communicating with each other via wireless links. The network's topology may change rapidly and unpredictably. Such networks II. SYSTEM MODEL may operate in a stand-alone fashion, or may be connected to the larger In- ternet. In traditional networks, hosts rely on centralized servers like DHCP We consider an autonomous Mobile Ad Hoc Network work- for configuration, but this cannot be extended to MANETs because of their ing on its own. It has no gateway or connection to the external distributed and dynamic nature. Many schemes have been proposed to solve this problem. Some of these approaches try to extend the IPv6 state- world. The network is formed by a group of nodes coming to- less autoconfiguration mechanism to MANETs, some use flooding the en- gether. The nodes can join and leave the network any time and tire network to come up with a unique IP address, and others distribute are free to move around. Hence the size and topology of the IP addresses among nodes (using binary split) so that each node can inde- network is dynamic and unpredictable in nature. pendently configure new nodes. None of these existing solutions consider network partitioning and merging. In this paper, we propose a proactive There is no single DHCP server.
    [Show full text]