1、 ETSI GS ORI 002-2 V4.1.1 (2014-10) Open Radio equipment Interface (ORI); ORI Interface Specification; Part 2: Control and Management (Release 4) Disclaimer This document has been produced and approved by the Open Radio equipment Interface (ORI) ETSI Industry Specification Group (ISG) and represents
2、 the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. GROUP SPECIFICATION ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)2Reference RGS/ORI-0018 Keywords control, interface, management, radio ETSI 650 Route des Lucioles F-06921 S
3、ophia 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org The present document
4、 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 i
5、n 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
6、 of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced or util
7、ized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to r
8、eproduction in all media. European Telecommunications Standards Institute 2014. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of
9、 the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)3Contents Intellectual Property Rights 8g3Foreword . 8g3Modal verbs terminology 8g31 Scope 9g32 References 9g32.1 Normative references . 9g32.2
10、Informative references 10g33 Definitions, symbols and abbreviations . 10g33.1 Definitions 10g33.2 Symbols 11g33.3 Abbreviations . 12g34 Introduction 13g35 C Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest
11、updates are available on the ETSI Web server (http:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web se
12、rver) which are, or may be, or may become, essential to the present document. Foreword This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Open Radio equipment Interface (ORI). The present document is part 2 of a multi-part deliverable covering the ORI Interfac
13、e Specification, as identified below: Part 1: “Low Layers (Release 4)“; Part 2: “Control and Management (Release 4)“. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “may not“, “need“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be i
14、nterpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)91 Scope The present document aims to define Contro
15、l and Management plane functions and protocols, addressing, message format and coding of the Open Radio equipment Interface (ORI) for Release 4. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific refer
16、ences, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: Whi
17、le any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the present document. 1 “Common Public Radio Interface (CPRI); Interface S
18、pecification“ V 6.0. NOTE: Available at http:/www.cpri.info/spec.html. 2 ETSI GS ORI 001: “Open Radio equipment Interface (ORI); Requirements for Open Radio equipment Interface (ORI) (Release 4)“. 3 ETSI GS ORI 002-1: “Open Radio equipment Interface (ORI); ORI Interface Specification; Part 1: Low La
19、yers (Release 4)“. 4 IEEE Std 802-2001: “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture“. 5 W3C Recommendation 28 October 2004: “XML Schema“ (part 0 to 2). NOTE: Part 0: Primer Second Edition http:/www.w3.org/TR/2004/REC-xmlschema-0-20041028/ Part 1: Structures Sec
20、ond Edition http:/www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Part 2: Datatypes Second Edition http:/www.w3.org/TR/2004/REC-xmlschema-2-20041028/ 6 The Unicode Consortium: “The Unicode Standard V6.0.0“; edited by Julie D. Allen . et al. Version 6.0, February 2011, ISBN 978-1-936213-01-6. NOTE: http
21、:/www.unicode.org/versions/Unicode6.0.0/. 7 W3C Recommendation 26 November 2008: “The Extensible Markup Language (XML) 1.0“ Fifth Edition. NOTE: http:/www.w3.org/TR/2008/REC-xml-20081126/. 8 IETF RFC 2045 (1996): “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodi
22、es“. NOTE: http:/www.ietf.org/rfc/rfc2045.txt. 9 ETSI TS 125 461 (V10.2.0): “Universal Mobile Telecommunications System (UMTS); UTRAN Iuant interface: Layer 1 (3GPP TS 25.461 version 10.2.0 Release 10)“. 10 ETSI TS 125 462 (V10.1.0): “Universal Mobile Telecommunications System (UMTS); UTRAN Iuant in
23、terface: Signalling transport (3GPP TS 25.462 version 10.1.0 Release 10)“. ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)1011 ETSI TS 125 466 (V10.3.0): “Universal Mobile Telecommunications System (UMTS); UTRAN Iuant interface: Application part (3GPP TS 25.466 version 10.3.0 Release 10)“. 12 Antenna Interf
24、ace Standards Group, Standard No. AISG v2.0, 13th June 2006: “Control interfaces for antenna line devices“. NOTE: Available at www.aisg.org.uk. 13 ETSI TS 125 215: “Universal Mobile Telecommunications System (UMTS); Physical layer; Measurements (FDD) (3GPP TS 25.215)“. 14 IETF RFC 959: “File Transfe
25、r Protocol“. 15 ISO/IEC 13239 (2002): “Information technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures“. 16 IETF RFC 2131: “Dynamic Host Configuration Protocol“. 17 IETF RFC 2132: “DHCP Options and BOOTP Vendor Extensions“. 18 IET
26、F RFC 793: “Transmission Control Protocol“. 19 ETSI TS 125 104: “Universal Mobile Telecommunications System (UMTS); Base Station (BS) radio transmission and reception (FDD) (3GPP TS 25.104)“. 20 ETSI TS 136 104: “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio trans
27、mission and reception (3GPP TS 36.104)“. 21 IETF RFC 950: “Internet Standard Subnetting Procedure“. 22 ETSI TS 136 211: “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation (3GPP TS 36.211)“. 23 ETSI TS 145 005: “GSM/EDGE Radio Access Network; Radio transmissio
28、n and reception (3GPP TS 45.005)“. 24 IETF RFC 826: “An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware“. 2.2 Informative references The following referenced documents are not necessary for the applica
29、tion of the present document but they assist the user with regard to a particular subject area. i.1 The Apache Software Foundation: “Apache log4cxx for C+“. NOTE: http:/logging.apache.org/log4cxx/index.html 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of the present docu
30、ment, the following terms and definitions apply: active link: See definition in 2. active software image: software image that is currently being executed on the RE Antenna Line Device (ALD): See definition in 12. Antenna-Carrier (AxC): See clause 2.1 of 1. ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)11DH
31、CP client: See definition in 16. DHCP server: See definition in 16. FTP password: See definition in 14. FTP server IP address: See definition in 14. FTP username: See definition in 14. universally unique MAC address: 48 bit universally administered, globally unique identifier in compliance with MAC-
32、48/EUI-48 format assigned to a network interface, as defined in IEEE Std 802-2001 4 HDLC control octet: See definition in 15. I-frame: See definition in 15. networking RE: See definition in 2. ORI line bit rate: See definition in 3. ORI link: See definition in 2. ORI port: See definition in 2. passi
33、ve link: See definition in 2. passive software image: software image that is not currently being executed on the RE radio standard: standardized radio access technology (e.g. UMTS, LTE, GSM) Received Total Wideband Power (RTWP): See 13. software image: software stored on the RE as a result of a succ
34、essful software upgrade that is compatible with the RE hardware version software upgrade package version identifier: information exchanged between the REC and the RE to identify the Software Upgrade Package software upgrade package: unique set of (one or several) files provided by the RE vendor for
35、the purpose of performing a software upgrade of one or more RE hardware versions provided by the same RE vendor, and associated with a maximum of one Software Image on the RE NOTE 1: The RE vendor should provide flexibility for supporting Software Upgrade Packages containing software for multiple ha
36、rdware versions and Software Upgrade Packages containing software for a single Hardware version. NOTE 2: Even if one of the files of a set changes, a new software upgrade package is created. TCP socket: See definition in 18. transceiver module: module that may be used to connect the internal circuit
37、s of the RE to the Layer 1 (see ETSI GS ORI 002-1 3) of the ORI link Uplink Automatic Gain Control (UL AGC): See definition in 3. 3.2 Symbols For the purposes of the present document, the following symbols apply: AxC Antenna-Carrier Rx Receiver Tc UTRA FDD chip period (1/3,84 MHz) THCI Health Check
38、Idle timer TTLM TCP Link Monitoring Timer ETSI ETSI GS ORI 002-2 V4.1.1 (2014-10)12Tx Transmitter Parameter used within the IQ data compression/decompression process NOTE: See further description of its usage in 3. 3.3 Abbreviations For the purposes of the present document, the following abbreviatio
39、ns apply: 3GPP 3rdGeneration Partnership Project AGC Automatic Gain Control AISG Antenna Interface Standards Group ALD Antenna Line Device ASCII American Standard Code for Information Interchange ARP Address Resolution Protocol AST Administrative StateAxC Antenna-Carrier C they shall not remove, ove
40、rride or re-define ORI specified parts of the interface. Vendor-specific extensions shall not impair the performance of standard compliant devices that do not have these extensions. Neither REC nor RE shall rely on the presence of such extensions to provide the ORI-defined functionality. Vendor spec
41、ific extensions, taking into account the rules above, are possible on all layers of the ORI. When receiving ORI compliant vendor specific elements, RECs and REs which are not aware of those shall tolerate them without failure (usually by ignoring them). A method for realization of extensions to the
42、RE Resource Model (additional parameters, or additional object types) is defined in clause 6.11. 6 RE Resource Model and its related Management Functions 6.1 Introduction The RE has a defined set of logical or physical resources that are to be managed by the REC. These resources are represented towa
43、rds the REC by data objects called “objects“, which are accessible by the REC through a set of common management functions. The set of defined objects and their relationship define the RE resource model. The role of the resource model is to provide an external management view of the REs capabilities
44、 to the REC, without relying on or revealing implementation details of the RE. In addition, the concept of using a dedicated resource model allows for modification and extension of the RE management interface while keeping the related management functions untouched. This simplifies specification mai
45、ntenance and reduces implementation and test effort. The purpose / scope of the resource model is to provide the following services to the REC: Configuration Management (CM): This service provides the RE configuration parameters, and read and modification access functions to configuration parameters
46、. It also provides the functions to manage the life cycle of dynamic Resource Model objects. In addition to RE configuration, this service is also used to provide information about capabilities of the RE (e.g. presence or number of certain physical or logical resources). ETSI ETSI GS ORI 002-2 V4.1.
47、1 (2014-10)17 State Management (SM): This service provides the state of resources (objects) in the RE, and read and modification access functions to states. It also provides a configurable notification service to the REC about state changes. Fault Management (FM): This service provides information a
48、bout the RE fault status, and access functions to get information about the status of fault reports. It also provides a configurable notification service to the REC about fault report state changes. Figure 6.1-1: System view of the Resource Model The individual objects of the Resource Model represen
49、t either physical or logical entities within the RE. Examples for physical entities are ports, like the ORI link ports or the antenna ports, but also the RE itself. Examples for logical entities are the Signal Paths, which bear configuration parameters for the processing of individual antenna carriers; they finally may be allocated and use physical resources, but do not represent these. An object consists of parameters, states and faults; not all of them need to b
