Standard

Available (2726)

Showing 2593 - 2604 per page



Network Functions Virtualisation (NFV); Use Cases

The scope of the present document is to describe use cases of interest for Network Functions Virtualisation (NFV). It updates and extends ETSI GS NFV 001 V1.1.1

The present document provides a review of previous use cases and adds some new use cases in the context of virtualisation that are related to emerging 5G features such as the Network Slicing concept, enhanced Security, IOT virtualisation.

  • Use Case #1: Network Function Virtualisation Infrastructure as a Service (NFVIaaS)
  • Use Case #2: VNF Forwarding Graphs
  • Use Case #3: Virtualisation of Mobile Core Network and IMS
  • Use Case #4: Virtualisation of Mobile base station
  • Use Case #5: Virtualisation of the Home Environment
  • Use Case #6: Virtual Content Delivery Network (vCDN) - Fulfilment
  • Use Case #7: Fixed Access Network Functions Virtualisation
  • Use Case #8: Crypto as a Service (CaaS)
  • Use Case #9: Network Slicing
  • Use Case #10: Virtualisation of Internet of Things (IoT)
  • Use Case #11: Rapid Service Deployment
  • Use Case #12: Devops/CI/CD
  • Use Case #13: A/B testing
  • Use Case #14: VNF composition across multiple administrative domains
  • Use Case #15: Security as a Service (SecaaS)

The order of use cases is not intended to give any priority amongst use cases.

These service models and use cases are intended to clarify the roles and interactions of the various types of commercial entities acting in a marketplace for services delivered via these VNFs. These actors include commercial entities/roles such as Service Providers, Enterprises, Consumers, etc. The fields of application provide high level descriptions of areas where the industry believes NFV technologies can be applied and which are representative of the business and technical challenges to be overcome.

The service models and use cases described in the present document are intended to provide a commercial and technical context that is expected to be useful for discussions to be handled s in further specifications to be developed by the NFV ISG. Other Industry forums may also find these service models and use cases helpful as they consider implementation options for virtualisation of the network functions they have previously standardized. The present document is not intended to provide detailed behavioural modelling of components of the NFV framework. Future documents describing additional components of the NFV framework may develop additional use cases to illustrate the behaviour of those NFV framework components; those components of the NFV framework, however, should be validated against the service models and fields of application described in the present document for consistency

GR NFV 001 V1.2.1

Network Functions Virtualisation (NFV); Architectural Framework

The present document describes the high-level functional architectural framework and design philosophy of virtualised network functions and of the supporting infrastructure. The document also defines the scope of the NFV Industry Specification Group (ISG) activities to realize this framework.
 
The purpose of the present document is to abstract the overall problem space in such a way that the requirements and aspects unique to NFV (ETSI GS NFV 004: "Network Functions Virtualisation (NFV); Virtualisation Requirements") are clearly identified so that the work can be scoped and organized. The resulting network architectural framework aims at positioning NFV among relevant telecommunications and IT industry stakeholders, including network operators, solution vendors, service integrators and providers, as well as serving as a reference to NFV ISG working groups.
 
Another purpose of the present document is to provide guidance to the industry Standards Development Organizations (SDOs) to align existing network related specifications with the NFV architectural framework outlined in the present document. Any further standardization of network functions, architecture and interfaces that are required to properly operate in a virtualised environment will be carried out in relevant SDOs. The resulting standards are expected to support the NFV high-level architectural requirements for both intra- and inter-provider domains.

GS NFV 002 V1.2.1

Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV

The present document provides terms and definitions for conceptual entities within the scope of the ISG NFV, in order to achieve a "common language" across all the ISG NFV working groups.

GS NFV 003 V1.4.1

Network Functions Virtualisation (NFV); Virtualisation Requirements

The present document specifies the requirements that Telecommunications operations put on Network Functions Virtualisation in order to consolidate network equipment, belonging to fixed and mobile networks, onto industry standard high volume servers, switches and storage, which could be located in N-PoPs, Network Nodes and in end user premises.
 
The present document addresses the requirements in the following areas:

  • Portability/Interoperability
  • Performance
  • Management and Orchestration
  • Elasticity
  • Security
  • Resiliency
  • Network Stability
  • Service Continuity
  • Operations
  • Energy Efficiency
  • Migration and co-existence with existing platforms

The present document addresses the requirements to facilitate the assignment of infrastructure resources to virtual network functions. Specific NFV requirements will focus primarily on the differences introduced by the Network Functions Virtualisation (NFV) process, and not on aspects of the Network Functions (NF) interfaces, protocols and management that are identical whether the implementation is physical or virtual.

GS NFV 004 V1.1.1

For Motion-Picture Film (32-mm) — 35-mm Film Perforated 32-mm, 2R

This standard specifies the cutting and perforating dimensions for 35-mm motion-picture film having two rows of 16-mm type perforations, one row near each edge of the 35-mm film, and a perforation pitch of either 0.2994 in or 0.3000 in (7.605 mm or 7.620 mm). The width of the 16-mm strip after processing and slitting is also specified.

SMPTE ST 73:2003

Sustainable cities and communities — Maturity model for smart sustainable communities

This document provides a top-level maturity model for smart sustainable communities (MMSSC), which can be used for self-assessment by individual cities and communities and as the basis for cross-city benchmarking. The MMSSC is a simple way for community leaders to assess how mature their community is in its journey towards adoption of good practices as set out in ISO standards for sustainable and smart-enabled development; to identify strengths and weaknesses; and then to quickly find their way to the international standards and guidance that are most relevant to their needs.

ISO/TS 37107:2019

Universal Business LanguageVersion 2.2

While industry-specific data formats have the advantage of maximal optimization for their busines scontext, the existence of different formats to accomplish the same purpose in different business domainsis attended by a number of significant disadvantages as well.  The OASIS Universal Business Language (UBL) is intended to help solve these problems by defininga generic XML interchange format for business documents that can be restricted or extended to meet the requirements of particular industries.

OCCI 1.2 Open Cloud Computing Interface – Text Rendering

This document, part of a document series produced by the OCCI working group within the Open Grid Forum (OGF), provides a high-level definition of a Protocol and API. The document is based upon previously gathered requirements and focuses on the scope of important capabilities required to support modern service offerings.
 
The Open Cloud Computing Interface (OCCI) is a RESTful Protocol and API for all kinds of management tasks. OCCI was originally initiated to create a remote management API for IaaS1 model-based services, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into a flexible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the Open Cloud Computing Interface is suitable to serve many other models in addition to IaaS, including PaaS and SaaS.
 
In order to be modular and extensible the current OCCI specification is released as a suite of complementary documents, which together form the complete specification. The documents are divided into four categories consisting of the OCCI Core, the OCCI Protocols, the OCCI Renderings and the OCCI Extensions.

  • The OCCI Core specification consists of a single document defining the OCCI Core Model. OCCI interaction occurs through renderings (including associated behaviors) and is expandable through extensions.
  • The OCCI Protocol specifications consist of multiple documents, each describing how the model can be interacted with over a particular protocol (e.g. HTTP, AMQP, etc.). Multiple protocols can interact with the same instance of the OCCI Core Model.
  • The OCCI Rendering specifications consist of multiple documents, each describing a particular rendering of the OCCI Core Model. Multiple renderings can interact with the same instance of the OCCI Core Model and will automatically support any additions to the model which follow the extension rules defined in OCCI Core.
  • The OCCI Extension specifications consist of multiple documents, each describing a particular extension of the OCCI Core Model. The extension documents describe additions to the OCCI Core Model defined within the OCCI specification suite.

The current specification consists of seven documents. This specification describes version 1.2 of OCCI and is backward compatible with 1.1.
 
This document presents the text-based renderings. To be complaint, OCCI implementations MUST implement the three renderings defined in sections 6, 7 and 8.
The following specification of the text-based renderings is in the process of being deprecated and will be removed or significantly changed in the next MAJOR release of the standard.
The document is structured by defining base ABNFs, which can then be combined into renderings, which will be rendered over a protocol (e.g., HTTP) by the specific rendering definitions.

GFD.229