1、 ETSI TR 126 981 V14.0.0 (2017-04) LTE; MBMS Extensions for Provisioning and Content Ingestion (3GPP TR 26.981 version 14.0.0 Release 14) TECHNICAL REPORT ETSI ETSI TR 126 981 V14.0.0 (2017-04)13GPP TR 26.981 version 14.0.0 Release 14Reference DTR/TSGS-0426981ve00 Keywords LTE ETSI 650 Route des Luc
2、ioles 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/stand
3、ards-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 content
4、s 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. I
5、nformation 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 Copyri
6、ght 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. The content of the PDF version shall not be modified without the written authorization of ETSI. The c
7、opyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2017. 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 ETS
8、I registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TR 126 981 V14.0.0 (2017-04)23GPP TR 26.981 version 14.0.0 Release 14Intellectual Property Rights IPRs essential or potenti
9、ally essential to the present document may have been declared to ETSI. 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, I
10、PRs notified to ETSI in respect of ETSI standards“, which is available 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 g
11、iven as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The presen
12、t document may refer to technical specifications or reports using 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:
13、/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In the present document “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“ an
14、d “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TR 126 981 V14.0.0 (2017-04)33GPP TR 26.981 version 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 5g3Introduction 5g31 Scope 6g32 Reference
15、s 6g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 Use-Cases . 7g34.1 Live Video from multiple cameras angles into a stadium 7g34.1.1 Use-Case Description . 7g34.1.2 Recommended requirements and working assumption . 7g34.2 Nation-Wide TV channels 8g34.2.1 Use-Case
16、Description . 8g34.2.2 Recommended requirements and working assumption . 8g34.3 VOD prepositioning . 9g34.3.1 Use-Case Description . 9g34.3.2 Recommended requirements and working assumption . 9g34.4 Software Update . 10g34.4.1 Use-Case Description . 10g34.4.2 Recommended requirements and working ass
17、umption . 10g34.5 TV Program Guide update delivery 10g34.5.1 Use-Case Description . 10g34.5.2 Recommended requirements and working assumption . 11g35 Architecture Considerations . 11g35.1 Introduction 11g35.2 Reference Model 12g35.3 Provisioning and Ingestion Procedures 12g35.3.1 Introduction. 12g35
18、.3.2 Provisioning and Ingestion Procedure for Live DASH services (MBMS Broadcast only) 13g35.3.3 Provisioning and Ingestion Procedure for Live DASH services (with Service Continuity) . 16g35.3.4 Provisioning and Ingestion Procedure for File Delivery Services (without File Schedule) 16g35.3.5 Provisi
19、oning and Ingestion Procedure for File Carousel Services 19g35.3.6 Provisioning and Ingestion Procedure for File Delivery Services using continuous Push ingest (without File Schedule) . 22g36 Security aspects 22g37 Survey of Existing Protocols for a Provisioning Interface . 22g38 Conclusions and Rec
20、ommendations . 24g3Annex A: Provisioning Procedure Overview 25g3A.1 Service, Session and Content Provisioning Overview . 25g3A.1.0 Workflow . 25g3A.1.1 Service Provisioning. 26g3A.1.2 Session Provisioning 26g3A.1.3 Content Provisioning 27g3Annex B: Abstract Representation of API using IDL . 28g3B.1
21、Introduction 28g3ETSI ETSI TR 126 981 V14.0.0 (2017-04)43GPP TR 26.981 version 14.0.0 Release 14B.2 Survey of Interface Description Languages . 28g3B.3 OMG IDL (Object Management Group Interface Description Language) 29g3Annex C: API Modelling Languages . 31g3C.1 Introduction 31g3C.2 RESTful API Mod
22、eling Language (RAML) 31g3C.3 Open API Initiative (successor of Swagger) 32g3Annex D: MB2 Reference Point . 38g3D.1 Introduction 38g3D.2 Shortcomings of MB2 38g3Annex E: Change history 40g3History 41g3ETSI ETSI TR 126 981 V14.0.0 (2017-04)53GPP TR 26.981 version 14.0.0 Release 14Foreword This Techni
23、cal Report has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TS
24、G 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 greater indicates TSG approved document under change control. y the second digit is incremented
25、 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 present document has been created as part of the study item on “MBMS Extensions on Provisioning
26、 and Content Ingestion“. The intention is to identify key functionality of an interface from external application service/content providers to the BM-SC for provisioning and content ingestion in order to leverage all delivery methods and procedures through the interface. Mechanisms that would be sui
27、table for delivery of multimedia content from external application service/content providers to the BM-SC should be identified. The provisioning and content ingestion interface definition should be aligned with the Client side APIs for MBMS (TRAPI) and the study on Enhanced TV Services. ETSI ETSI TR
28、 126 981 V14.0.0 (2017-04)63GPP TR 26.981 version 14.0.0 Release 141 Scope The present document is a study of an interface from external content providers to the BM-SC for provisioning and content ingestion. 2 References The following documents contain provisions which, through reference in this tex
29、t, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In
30、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 Release as the present document. 1 3GPP TR 21.905: “Vocabulary for 3GPP Specifications“. 2 3GPP TS 22.246: “Multimedia Broadcast/Multic
31、ast Service (MBMS) user services; Stage 1“. 3 3GPP TS 26.346: “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs “. 4 3GPP TR 26.917: “MBMS/PSS Enhancements to Support Television Services“. 5 3GPP TR 23.746: “Study on System Architecture Enhancements to eMBMS for Television Video S
32、ervice“. 6 3GPP TS 23.468: “Group Communication System Enablers for LTE (GCSE_LTE); Stage 2“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 1 and the following apply. A term defined in the present document
33、takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 1. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 1 and the following apply. An abbreviation defined in the present document takes precedence over the definition of
34、 the same abbreviation, if any, in 3GPP TR 21.905 1. ADF Associated Delivery Function API Application Programming Interface BM-SC Broadcast Multicast Service Center CP Content Provider DASH Dynamic Adaptive Streaming over HTTP DRM Digital Rights Management GBR Guaranteed Bitrate GUI Graphical User I
35、nterface MBMS Multimedia Broadcast/Multicast Service MPD Media Presentation Description MSA MBMS Service Area ETSI ETSI TR 126 981 V14.0.0 (2017-04)73GPP TR 26.981 version 14.0.0 Release 14MDF MBMS (Download & Streaming) Delivery Function SAF User Service Discovery / Announcement Function SACH Servi
36、ce Announcement Channel TMGI Temporary Mobile Group Id TV Television URL Uniform Resource Locator VoD Video on Demand 4 Use-Cases 4.1 Live Video from multiple cameras angles into a stadium 4.1.1 Use-Case Description A Content Provider wants to offer multiple camera angles of a sports match into stad
37、iums. The role of the Content Provider and the role of the network operator may be in the same organization. When the roles are separated across companies, the procedure remains the same and additional authorization and security functions may be added. The Content Provider wants to offer for example
38、 four live feeds and a statistics or replay channel around the ongoing match into the stadium. Only devices inside of the stadium are supposed to receive the content streams. The Content Provider negotiates service related aspects like the broadcast areas (i.e. locations of the stadiums), the broadc
39、ast times (i.e. times of the matches) and the media quality (i.e. desire bitrates, etc.) with the operator. The network operator (i.e. BM-SC operations) offers the Content Provider APIs or a self-service GUI for session and content provisioning. The Content Provider authenticates itself in order to
40、use the self-service features. After authorization, the Content Provider can plan and provision sessions and content within the negotiated range. The Content Provider plans and provisions MBMS Broadcast session by providing start and stop time, the target MBMS Broadcast area and the expected content
41、 bitrate, including tolerable losses (note, amount of AL-FEC redundancy should be hidden to the Content Provider). For each MBMS Broadcast session, the Content Provider may needs to determine whether one or more delivery sessions are provided with the same MBMS Bearer. The Content Provider uses MBMS
42、 Broadcast for the Live Data. The Content Provider provides service information before and after the broadcast session using unicast. Devices receive the transport control metadata before the Content Provider starts the content streams. The operator may use a Service Announcement Channel (SACH) for
43、the purpose of distributing service announcement information. Devices may receive additional service information using unicast. 4.1.2 Recommended requirements and working assumption Working assumptions: - The Content Provider and the operator have a business agreement. - The Content Provider owns th
44、e content rights to distribute the content. - The Content Provider and the network operator role may belong to the same company. - The Content Provider secures a dedicated App, which is used by end-users for consuming the service. The App uses the MBMS Client APIs, aligned with offering principle of
45、 the Content Provider. - The Content Provider controls the content preparation chain. - The App/Content Provider can utilize unicast for additional communications e.g. when the MBMS broadcast bearer is not active. ETSI ETSI TR 126 981 V14.0.0 (2017-04)83GPP TR 26.981 version 14.0.0 Release 14- The S
46、ervice Announcement Channel (SACH) is used to distribute MBMS Service Announcement information. Recommended Requirements: - The interface (between BM-SC and the Content Provider) should support authentication procedures so that only authorized Content Providers can change GUI view and/ or modify the
47、 session information. The interface may support different levels of authorization, e.g. for system administrators to configure the negotiate usage ranges and system users to select a certain parameter set of a broadcast session. - The operational complexity of sending content via broadcast should be
48、 hidden as much as possible to Content Providers. - The Content Provider should be able to select a content ingestion method into the system, e.g. for large files and for small files. The interface should allow selecting different methods. - The interface allows separation of different provisioning
49、steps. - The Content Provider provides an MPD and the needed Initialization Segments to the operator to create the service announcement information. The Content Provider may need to update the MPD during the broadcast. The interface supports providing a first MPD, providing updated MPDs and providing Initialization segments. 4.2 Nation-Wide TV channels 4.2.1 Use-Case Description A Content Provider wants to offer nation-wide TV channels. The Content Provider negotiates with the operator the media quality and the service area (i.e. nation-wide). The use-case