ETSI TS 132 391-2017 Digital cellular telecommunications system (Phase 2+) (GSM) Universal Mobile Telecommunications System (UMTS) LTE Telecommunication management Delta synchroniz.pdf

1、 ETSI TS 132 391 V14.0.0 (2017-04) Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Delta synchronization Integration Reference Point (IRP); Requirements (3GPP TS 32.391 version 14.0.0 Release 14) TECHN

2、ICAL SPECIFICATION ETSI ETSI TS 132 391 V14.0.0 (2017-04)13GPP TS 32.391 version 14.0.0 Release 14Reference RTS/TSGS-0532391ve00 Keywords GSM,LTE,UMTS 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 74

3、2 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/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic an

4、d/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) versio

5、n 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/ETSIDeliverableStat

6、us.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 photoco

7、pying 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 reproduction in all media. European Telecommunications Standards Institute 201

8、7. 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 the 3GPP Organizational Partners. oneM2M logo is protected for the benefit o

9、f its Members GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 132 391 V14.0.0 (2017-04)23GPP TS 32.391 version 14.0.0 Release 14Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI.

10、The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available

11、from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/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 31

12、4 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports usin

13、g their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In t

14、he present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted 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 deliv

15、erables except when used in direct citation. ETSI ETSI TS 132 391 V14.0.0 (2017-04)33GPP TS 32.391 version 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 4g3Introduction 4g31 Scope 5g32 References 5g33 Definitions and abbreviations . 5g3

16、3.1 Definitions 5g33.2 Abbreviations . 6g34 Requirements for Delta Synchronization between IRP Manager and IRP Agent 6g34.1 Concept 6g34.2 General requirements . 7g34.3 Requirements for operations related to delta synchronization 7g3Annex A (informative): Change history . 9g3History 10g3ETSI ETSI TS

17、 132 391 V14.0.0 (2017-04)43GPP TS 32.391 version 14.0.0 Release 14Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval.

18、 Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or gr

19、eater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction The pr

20、esent document is part of a TS-family covering the 3rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; as identified below: 32.391: “Delta Synchronization Integration Reference Point (IRP): Requirements“. 32.392: “Delta Synchron

21、ization Integration Reference Point (IRP); Information Service (IS)“. 32.396: “Delta Synchronization Integration Reference Point (IRP); Solution Set (SS) definitions“. The Itf-N interface is built up by a number of IRPs and a related Name Convention, which realise the functional capabilities over th

22、is interface. The basic structure of the IRPs is defined in 3GPP TS 32.101 1 and 3GPP TS 32.102 2. IRPManagers (typically Network Management Systems) and IRPAgents (typically EMs or NEs) synchronize their data concerning alarms or configuration data. In certain scenarios this synchronization is lost

23、 or not done. This IRP provides functionality to significantly reduce the amount of data which needs to be transferred in order to re-establish synchronization. ETSI ETSI TS 132 391 V14.0.0 (2017-04)53GPP TS 32.391 version 14.0.0 Release 141 Scope The purpose of Delta Synchronization IRP is to defin

24、e an interface through which an IRPManager can request only those data which changed (i.e. changed, were created or deleted) from a synchronization point onwards. The present document contains the Requirements of Delta Synchronization IRP. It defines, for the purpose of Delta Synchronization, the ba

25、sic requirements to be fulfilled on Itf-N. 2 References The following documents contain provisions that, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non-sp

26、ecific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same R

27、elease as the present document. 1 3GPP TS 32.101: “Telecommunication management; Principles and high level requirements“. 2 3GPP TS 32.102: “Telecommunication management; Architecture“. 3 3GPP TS 32.302: “Telecommunication management; Configuration Management (CM); Notification Integration Reference

28、 Point (IRP); Information Service (IS)“. 4 3GPP TS 32.342: “Telecommunication management; File Transfer (FT); Integration Reference Point (IRP); Information Service (IS)“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions ap

29、ply: changed instance / alarm: it refers to a managed object instance or an alarm that has changed during a period defined two time based references A managed object instance / alarm is considered changed if: a) It is present at the beginning of the period and absent at the end of the period; or b)

30、It is absent at the beginning of the period and present at the end of the period; or c) At least one of its attribute / parameter values is different at the beginning and at the end of the period. CM data: data which can be managed by CM (no matter if basic or bulk CM) delta synchronization: state o

31、f MIB is the totality of states of all managed object instances in that MIB State of MIB can be changed. AlarmList content can be changed. Delta synchronization refers to a process where the IRPManagers view of the MIB state or the AlarmList content at T1 (sometimes referred to as the beginning of t

32、he Delta Synchronization period) can be updated to that at T2 (sometimes referred to as the end of the Delta Synchronization period) by receiving and processing only those data involving changed instances. delta synchronization point: it refers to a point in time based on the clock used by the IRPAg

33、ent It relates to the T1 and T2 of the Delta Synchronization process. ETSI ETSI TS 132 391 V14.0.0 (2017-04)63GPP TS 32.391 version 14.0.0 Release 14FM data: alarm data as it would be retrieved with operation getAlarmList full synchronization: it is a specialized Delta Synchronization process in tha

34、t at T1 (beginning of the Delta Synchronization period), there is no managed object instance or the AlarmList content is empty IRP: See 3GPP TS 32.101 1. IRPAgent: See 3GPP TS 32.102 2. IRPManager: See 3GPP TS 32.102 2. 3.2 Abbreviations For the purposes of the present document, the following abbrev

35、iations apply: CM Configuration Management EM Element Manager IRP Integration Reference Point IS Information Service (see 3GPP TS 32.101 1) Itf-N Interface N MIB Management Information Base NE Network Element 4 Requirements for Delta Synchronization between IRP Manager and IRP Agent 4.1 Concept Delt

36、a Synchronization allows an IRPManager to request information about changes which took place since a specific point in time (synchronization point) and applies both to the alarm list and configuration data. This gives the IRPManager an efficient way to align his picture with the picture the IRPAgent

37、 has. 4.1.1 Difference to full synchronization: “Full synchronization“, provided in TS 32.60n and 32.111-n series by operations such as getMOAttributes and getAlarmList, on the other hand delivers - in the requested scope (and filter, if applied) - the complete data at that point in time when the IR

38、PAgent prepares the response to such an operation request. For all cases when only a few data have changed, a “full synchronization“ would deliver too many data and the potentially huge amount of data would have to be checked where changes took place. Delta synchronization can be beneficial in these

39、 cases. This benefit would be destroyed, if in responses to delta synchronization request the IRPAgent would deliver the same data as in full synchronization responses. Therefore this is not allowed (except in the trivial cases where the changed data is identical to the existing data). 4.1.2 Differe

40、nce to logging: A suitably administered log contains a history of the changes which took place, potentially also since the synchronization point. But many of these changes could refer to the same instances which e.g. changed several times or where changes were undone again. Delta synchronization tri

41、es to compress this information as far as possible to only one set of delta synchronization data per changed instance and not to report undone changes. Therefore it is not allowed to deliver the full change history since the synchronization point (except for those trivial cases when there were no “c

42、ompressible“ changes). NOTE: Delta synchronization not necessarily has to be based on a log. For cases where changes take place which are not recorded in a log - e.g. because the changes do not result in a notification to be logged - using the log would fail to produce the correct delta synchronizat

43、ion data. ETSI ETSI TS 132 391 V14.0.0 (2017-04)73GPP TS 32.391 version 14.0.0 Release 144.2 General requirements 4.2.1 Data which require delta synchronization: 4.2.1.2 CM data 4.2.1.2 FM data 4.2.2 Scenarios when delta synchronization can be required: 4.2.2.1 IRPManager recognizes that its data ma

44、y not be up-to-date 4.2.2.2 Interruption and re-establishment of the Manager-Agent communication (especially useful for interruptions when not a very big amount of data changed) 4.2.2.3 IRPAgent does not generate CM-related notifications (notifyObjectCreation / notifyObjectDeletion / notifiyAttribut

45、eValueChange) 4.2.2.4 IRPManager does not evaluate CM-related notifications (notifyObjectCreation / notifyObjectDeletion / notifiyAttributeValueChange) 4.2.2.5 IRPManager regularly synchronizes its data 4.2.3 Time aspects 4.2.3.1 Time parameters in the context of the delta synchronization refer to t

46、he IRPAgents time. 4.3 Requirements for operations related to delta synchronization 4.3.1 The Itf-N shall allow an IRPManager to request delta synchronization data for the managed resources of the whole or optionally only a part of the network. 4.3.2 The Itf-N shall allow an IRPManager to specify in

47、 its request if it wants delta synchronization data starting from a synchronization point in time or from the last synchronization (i.e. the last time the IRPAgent stored a section of the delta data). The IRPAgent may choose to only accept a request for delta data related to the IRPAgents own synchr

48、onizationPoints 4.3.3 The Itf-N should allow an IRPManager to request if it wants in delta synchronization responses - only the identification of the changed instances (concerning configuration or alarm status) or - the complete data (attributes/parameters) of the changed instances (including identi

49、fication). This choice is not possible, if the delta data is delivered in files, not in the operation response. 4.3.4 The IRPAgent shall indicate in its response to the delta synchronization request whether the delivered data is new, was modified or deleted since the last delta synchronization / last getAlarmList / last getMOattributes / synchronization point. 4.3.4.1 If an instance is created and deleted again / an alarm is raised and cleared again and acknowledged, then both should not be reported, if the IRPAgent can fulfil the delta synchronization