WO2018075930A1 - Détermination et communication d'attributs de posture de sécurité - Google Patents

Détermination et communication d'attributs de posture de sécurité Download PDF

Info

Publication number
WO2018075930A1
WO2018075930A1 PCT/US2017/057661 US2017057661W WO2018075930A1 WO 2018075930 A1 WO2018075930 A1 WO 2018075930A1 US 2017057661 W US2017057661 W US 2017057661W WO 2018075930 A1 WO2018075930 A1 WO 2018075930A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
security
node
spv
security posture
Prior art date
Application number
PCT/US2017/057661
Other languages
English (en)
Inventor
Yogendra C. Shah
Vinod Kumar Choyi
Ayman ABDELHAMID
Samir Ferdi
Alec Brusilovsky
Original Assignee
Idac Holdings, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idac Holdings, Inc. filed Critical Idac Holdings, Inc.
Publication of WO2018075930A1 publication Critical patent/WO2018075930A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security

Definitions

  • Example use cases include Enhanced Mobile Broadband (eMBB) connectivity, Massive Internet of Things (MIoT), and Ultra-Reliable Low Latency Communications (URLLC) services.
  • eMBB Enhanced Mobile Broadband
  • MIoT Massive Internet of Things
  • URLLC Ultra-Reliable Low Latency Communications
  • An additional driver in 5G is the need for increased service reliability for mission critical communications services, such as intelligent transportation systems for example.
  • mission critical communications services such as intelligent transportation systems for example.
  • NIS Network Infrastructure Security
  • NS Described herein is a systematic framework and approach that may be used to assess and measure the level of trust (or risk involved with regard to the various deployment models and services to be provided), and to aid secure delivery of the anticipated 5G services through slices, individual network functions, or traditional network infrastructure. Furthermore, the processes for deriving and measuring the level of trust takes into consideration the policy requirements from different stakeholders, and takes into consideration security attributes that are important to the stakeholder in evaluating the level of trust. It is recognized herein that the latter part may be critically important for 5G networks because much of the infrastructure may be shared or leased, and not owned by the operators and service providers.
  • a first node comprises, a processor, a memory, and communication circuitry.
  • the first node is configured to connect to a communications network via the communication circuitry, and the first node comprises computer-executable instructions stored in the memory of the first node which, when executed by the processor of the first node, perform various operations.
  • the operations include obtaining or deriving a Security Posture Value (SPV) associated with a second node.
  • SPV Security Posture Value
  • the derivation of the SPV may be based on a full 360° security assessment of a second node.
  • the assessment may include, and thus the SPV may be based on, physical and cyber security attributes associated with the second node.
  • the SPV may provide a verifiable trust metric on an overall level of trust in the second node.
  • the SPV may also be derived based on policies of at least one, for instance a plurality of, stakeholder service provider entity.
  • the second node is a network function.
  • the first and second node are network functions within a network slice comprising a plurality of network functions.
  • a first node determines a network configuration that includes a chain of nodes from the first node, through a second node, to a destination node. Based on physical and cyber security attributes associated with the second node, the first node obtains a security posture value associated with the second node. The first node may receive a data packet, and obtain a security posture level requirement associated with the data packet. The first node can determine whether to forward the data packet to the second node, based on the security posture value associated with the second node. In some cases, the first node forwards the data packet to the second node when the security posture value is sufficient relative to the security posture level requirement associated with the data packet. BRIEF DESCRIPTION OF THE DRAWINGS
  • Fig. 1 depicts example business models in 5G networks.
  • Fig. 2 depicts three dimensions considered for 5G networks.
  • FIG. 3 depicts a conceptual outline of network slicing.
  • Fig. 4 illustrates an example of Network Functions Virtualization (NFV) layers.
  • NFV Network Functions Virtualization
  • Fig. 5 depicts an example NFV architectural framework.
  • Fig. 6 depicts an example deployment architecture with multiple operator domains.
  • Fig. 7 depicts an overview of software defined networking (SDN).
  • Fig. 8 illustrates an example of a mobile video service deployed on a network slice (NS) spanning two data centers (DCs).
  • NS network slice
  • DCs data centers
  • Fig. 9 shows an example of network service header contents.
  • Fig. 10 depicts an example of service function chaining (SFC) control with
  • Fig. 11 shows example security attributes for some components in a 5G network, in accordance with an example embodiment.
  • Fig. 13 shows an example SFC based on security posture values in accordance with an example embodiment.
  • Fig. 15 shows an example of security requirements using a security-as-a-service (SECaaS) model in accordance with an example embodiment.
  • SECaaS security-as-a-service
  • Fig. 16 is a diagram of an example infrastructure network architecture for two mobile network operators (e.g., Verizon and T-Mobile).
  • two mobile network operators e.g., Verizon and T-Mobile.
  • Fig. 17A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.
  • Fig. 17B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in Fig. 17A according to an embodiment
  • WTRU wireless transmit/receive unit
  • Fig. 17C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in Fig. 17A according to an embodiment.
  • RAN radio access network
  • CN core network
  • Fig. 17D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in Fig. 17A according to an embodiment.
  • next generation networks which can also be referred to as 5G systems, without limitation, are to cater to a variety of connected industries, such as manufacturing and processing, intelligent transportation, smart grid, e-health, and internet of things (IoT), as well as traditional high speed data services.
  • IoT internet of things
  • Such diverse use cases and environments bring the challenge of a wide range of service layer requirements (e.g., QoS such as speed, latency, security, error rate, reliability, and
  • an e-health information system may require more privacy than a Home Automation System (HAS) that needs more security for Control Plane (CP) signaling.
  • HAS Home Automation System
  • CP Control Plane
  • Radio Network equipment that supports higher frequencies (e.g., Millimeter waves: 30GHz+), and core networks that can store, forward and process the data may have to be designed and deployed, thus creating an increase in capital and operating expenditures by mobile network service providers.
  • an MNO can be an asset provider 95, connectivity provider 97, or partner service provider 99 as shown in Fig. 1.
  • the asset provider 95 owns a certain function of the network (partially/fully sharing the RAN and/or the core network).
  • the connectivity provider 97 can refer to an MNO that does not own any infrastructure, but provides a network (e.g., IP) connectivity that is offered to a
  • Context-awareness allows for customization or creation of an application to match the preferences of the individual user, based on current context (e.g., location, time, activities and services).
  • a 5G network may support fixed and mobile convergence in order to ensure a seamless customer experience within the fixed and mobile domains (e.g., a unified user authentication, RAN and CN independence).
  • Enhanced Network Security refers to improving the security protocols to adapt to newly introduced use-cases (e.g., MIoT), and, in some cases, complying with security requirements defined in 3GPP standards.
  • Network Slicing can be used to offer more granular control of performance and network features based on the application or services being used.
  • Network Slicing can be defined as a way to provide isolated sub-networks or integration of a choice of network components to define a network, each optimized for specific types of traffic characteristics.
  • Each network slice has its own set of security and QoS requirements and slices may be completely isolated from each other.
  • a Slice is defined as a set of features that achieves the requirements of a certain use-case, taking into consideration the capabilities of the operator(s) who provide this service.
  • a slice is defined in more detail below, taking into account the current 3GPP standard procedures and protocols.
  • 5G networks may support dedicated vertical use cases such as, for example, intelligent transportation, gaming, remote machinery and virtual reality. These use cases may have different service requirements.
  • virtual slices of the network that support the requirements may be designed. Such virtual Slices are logical instantiations of the required network resources. Using automated management based on NFV technologies, operators/service providers may support such a slicing.
  • FIG. 3 An example description of network slicing is shown in Fig. 3.
  • a network operator may use a Network Slice Blueprint to create a Network Slice Instance 302.
  • a particular Network Slice Instance 302 may provide the network characteristics (including the layers from the Radio Access layer up to the service layer) that are required by a Service Instance 304.
  • a Network Slice Instance 302 may also be shared across multiple Service Instances 304 provided by the network operator.
  • NFV Network Function Virtualization
  • VNFI Virtual Machine Instance
  • VNFCI VNF Component Instance
  • a Virtual infrastructure (NFVI) 402 can include a plurality of virtual machines 404 running on generic high-volume hardware servers and storage devices, connected by generic high-volume network switches and organized by an orchestration function 406 (e.g., Hypervisor).
  • the architecture can separate software that defines network functions 408 for network devices from generic hardware 410.
  • the orchestration function 406 may automate installation and management of the virtualized network functions 408 on the generic hardware 410.
  • an example NFV system 500 includes a Management and Orchestration (MANO) function 502 within NFV can manage the NFV Infrastructure (NFVI) 402 and perform resource allocations that are needed by the various network services and VNFs 408.
  • the MANO 502 may be involved in the management and orchestration of the Network Functions Virtualization Infrastructure 402, which may include components that are managed and that may be virtualized or partially-virtualized resources.
  • Example resources include computing infrastructure, which may include both computing machines and virtual machines having both CPU and memory.
  • the resources may also include storage resources (e.g., non-volatile secure storage) and network resources (e.g., subnets, ports, networks, etc.).
  • the MANO 502 may manage and orchestrate Virtualized Network Functions 408 pertaining to fault, configuration, accounting, provisioning and security (FCAPS).
  • the MANO 502 may instantiate, scale, upgrade, and terminate VNFs 408.
  • the MANO 502 may manage the lifecycle of network services, for example the instantiation of services, scaling (elasticity), and termination of services.
  • the MANO 502 may also perform policy management, and may manage interactions with legacy or new Operations Support Systems/Business Support Systems (OSS/BSS) 504.
  • OSS/BSS Operations Support Systems/Business Support Systems
  • the NFV system 500 may also include the NFV Orchestrator (NFVO) 406, which may interact with the OSS/BSS 504, and possibly legacy systems, for provisioning, configuration, capacity management, policy-based management, and lifecycle management of network services.
  • NFVO NFV Orchestrator
  • the NFVO 406 may also perform overall orchestration of the use of resources for a network slice (NS), which may span across multiple VIMs.
  • NS network slice
  • the NFV system 500 includes a VNF Manager (VNFM) 506, which may be responsible for lifecycle management of VNF instances.
  • VNFM VNF Manager
  • the NFV system 500 may include a Virtualized Infrastructure Manager (VIM) 508, which is responsible for controlling and managing the NFVI compute, storage, and network resources, for instance within one operator's Infrastructure Domain (e.g., NFVI-PoP).
  • VIP Virtualized Infrastructure Manager
  • Network Controllers 604 under VIM control may be software defined networking (SDN) Controllers, which are described in further detail below.
  • SDN Software Defined Networking
  • a complementary technology to the previously mentioned NFV is SDN, which enables realization of the control plane, user plane, and management plane for NFV.
  • SDN enables network function virtualization and network programmability, which are the protocol building blocks for the next generation of 5G networks.
  • the SDN network architecture consists of a centralized network controller 702 in the control plane 704, which is responsible for allocating traffic to network elements in the separated data plane of the network, as shown in Fig. 7.
  • the network controller 702 centrally maintains the intelligence and state of the entire network. Therefore, the network controller 702 can output the best fine granular flow routing control rules to the heterogeneous network devices 706 from different vendors.
  • the network controller 702 can provide a global united view and resources of the network to the upper layer network applications 708 as a single, logical switch.
  • novel network applications can be created, tested, and deployed in a short time.
  • SDN protocols can enable control-plane management and is separated from the data/user plane.
  • Open flow is defined by the Open Networking Foundation (ONF) and is broadly accepted as the dominating SDN protocol in a southbound interface 705 between the network controller 702 and network devices 706. It is widely supported by various device manufacturers, service providers, and operators. Additionally, ForCES and PCE, defined by the Internet Engineering Task Force (IETF), are alternative southbound SDN protocols.
  • ONF Open Networking Foundation
  • Fig. 8 illustrates the topology and layers of an example NS for an eMBB use case, using a hypothetical "OTT mobile video streaming service with QoS" scenario as detailed in Fig. 8, which shows different views of the service from top to bottom.
  • the views include a customer/business view 802 (high level specification of the service and expected SLA); a design view 804 (abstract graph from the service designer perspective); an orchestration view 806 (service composition with specific NFs, connection points and links (e.g., VNF Forwarding Graph (VNF-FG)); and a deployment view 808 (mapping of the above onto a NS allocated from a specific NFVI and the underlying packet switching and routing infrastructure fabric).
  • VNF-FG VNF Forwarding Graph
  • Core MNO service functions e.g., management, control, and user plane functions
  • service differentiation functions e.g., Internet access, video/TCP optimization, firewall, and CDN functions
  • an MNO owns the network infrastructure such as the NFVI-Point of Presence (NFVI-POP), and may provide an enhanced video streaming service in partnership with an OTT provider (e.g., revenue sharing).
  • NFVI-POP NFVI-Point of Presence
  • OTT provider e.g., revenue sharing
  • the MNO network is also shared with other tenants with different service offerings. Therefore, the MNO has in place a framework to support network slicing.
  • the RAN could be deployed into a Cloud RAN architecture where the CDN cache function in particular would be deployed, reducing download latency for the end user and backhaul/core network traffic for the operator.
  • the slicing may also span across the Cloud RAN infrastructure as well, however the evaluation of the NS SPV principle would remain the same, albeit with additional detail elements in the RAN NFVI.
  • the MNO network management functions of network provisioning and management based on a NS using NFV rely on an underlying packet switching and routing fabric, a service which may be provided by many underlying internet connectivity providers from private networks through to public networks.
  • These network infrastructure components reside in data centers (DC) and comprise physical and virtual switches/routers
  • vSwitch/vRouter a WAN Infrastructure Manager (WIM), and WAN SDN controllers (not shown in the figure for simplicity) as shown in Table 1 and Table 2 below.
  • WIM WAN Infrastructure Manager
  • the MNO network management functions sit on top of this underlying packet switched network as shown in Table 3 and Table 4.
  • the SDN controllers help to setup the Network Connectivity Topology (NCT) and program the various NFPs.
  • NCT Network Connectivity Topology
  • One aspect of the NS is to achieve per tenant/service traffic isolation, which is accomplished in the example by tunneling the service traffic through an overlay of VxLAN tunnels.
  • DO Data Center Interconnect
  • the core infrastructure fabric requires the highest grade of security since it provides the trust anchor for the services, which sit on top of the packet switched network communications fabric.
  • the infrastructure provided overlay networking does not provide any security features on its own (as others such as MPLS or
  • a protection mechanism e.g., IPS/Firewall, ACL
  • IPS/Firewall ACL
  • a deployment hypothetically connecting NFs through a 3rd party ISP may require appropriate data protection mechanisms to carry data between NFs (e.g., IPsec tunnels).
  • NFs e.g., IPsec tunnels
  • VNFs from 3rd party vendors may be up to the SN (or service provider) to ensure adequate protection by means of additional security functions (e.g. IPSec gateways).
  • VNFs and Network Service management and orchestration is performed by the NFVO, which controls the VIMs deployed in the various Data Centers (DC).
  • DC Data Centers
  • the NVFO deploys the VNF-FG "Core" portion through the Core DC VIM and the
  • the VNF-FG contains NCT for service topology and NFP for dynamic SFC.
  • the VIM uploads the NCT and SFC information into the SDN controller via an Application Control Interface (ACI), and deploys the various VNFs
  • VMs on the appropriate compute nodes.
  • the NVFO performs lifecycle management of each VNF through its associated VNFM (not shown here for simplicity).
  • the Infrastructure forms clusters of compute servers running the hypervisors which host the VMs and the vSwitches/vRouters required respectively to run and connect the VNFs together.
  • management plane may require the highest level of security.
  • a low level of security for any of the management entities could potentially translate into severe vulnerabilities that may lead to attacks impacting an entire DC or network.
  • a malicious entity taking control of the NFVO could gain privileged access to otherwise highly protected resources (VIM, SDN controllers etc.) throughout the network via the management interfaces.
  • DCI GW/PE Data Center Interconnect GW also acts as Edge Core DC Ingress & Egress IP, VxLAN DCI
  • Compute/Storage x86 high volume servers in racks/pods Central DC IP, SDN Control, Nf-Vi clusters Core DC
  • control plane functions provide the traditional control plane functions of an MNO network such as access control, mobility management, and session management functions, which may be partitioned into more specific functions underlying functions and placed in different virtual machines as shown in Table 5 and Table 6.
  • control plane functions may require a higher grade of security than the user plane functions because, similar to the management plane functions, any compromise in this function can compromise the user plane functions.
  • control plane may tolerate a lower level of security than a management plane.
  • Table 5 Example Network Service (VNF-FG) Control Plane components
  • VNFC Mobility Anchor-C - VNF component
  • VNFC Internet GW-C - VNF component
  • the user plane functions provide the traditional user plane functions for transporting user data through an MNO network.
  • the user plane may tolerate the lowest level of security as shown in Table 7 and Table 8.
  • Mobility Anchor-U mobility anchored user data forwarding Core DC User Data
  • Internet GW-U internet gateway user data forwarding Core DC User Data
  • SFC Service Function Chaining
  • SF Service Functions
  • SFC aims to remove any topological coupling between a service deployment and the underlying network to achieve flexible and fully dynamic Service Function (SF) insertion and chaining.
  • An example of an abstract service function is "a firewall”.
  • SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed.
  • a Service Forward Path (SFP) which represents a particular SFC instance specifies the ordered list of SFs that process a particular packet based on policy or operational context.
  • a Network Service Header can be an enabler to dynamic SFC deployment.
  • the NSH can define a new data plane protocol specifically for the creation of dynamic service chains.
  • the NSH can address the limitations of static SFCs, as captured by the SFP including, for example, topology dependency, monitoring and troubleshooting a SFC, classification and re-classification realization in SDN Open Flow switches, and transport layer protocols dependency (NSH is transport agnostic).
  • the NSH header may contain service path information and optionally metadata that is added to a packet or frame and used to create a service plane as shown in an example NSH header 900 depicted in Fig. 9.
  • the original packets preceded by NSH can be encapsulated in an outer header for transport.
  • the Service Path Header 902. includes a Service Path Identifier (SPI) 904 and a Service Index (SI) 906.
  • SPI 904 identifies a certain service path.
  • SI 906 provides the location within the service forward path (SFP).
  • Service index may be decremented by service functions or proxy nodes after performing required services and the new decremented SI value is reflected in the egress NSH packet.
  • functions involved in a SFC and their role vis-a-vis NSH include, by way of example and without limitation, include a service classifier (SC) 1002, a service function (SF) 1004, and a service function forwarder (SFF) 1006.
  • SC service classifier
  • SF service function
  • SFF service function forwarder
  • the Service Classifier (SC) 1002 may be responsible for inserting NSH based on traffic classification. Re-classification along the path is possible with multiple SCs, which can alter existing NSH or insertion of a new one.
  • the Service Function (SF) 1004 may be responsible for specific processing of received packets. SF also decrements the SI in the NSH of a handled packet.
  • the Service Function Forwarder (SFF) 1006 may be responsible for forwarding traffic to one or more SFs or another SFF based on information carried by the NSH. In some cases, the last SFF in a SFP removes the NSH header.
  • the network slice provisioning process involves the elements starting from the top management layer (NFV Orchestrator) all the way down to the Virtualized Infrastructure Manager (VIM) and NFV Infrastructure (NFVI).
  • the network slice creation process consists of partitioning and allocating compute, storage, and network resources from the NFVI pool and configuring them with a set of VNFs with their inter-links.
  • ESTI has identified 3 sub-domains within NFVI: Compute
  • the NFVO has a global view of the network slice definition in the form of a logical chained graph of VNFs called Forwarding Graph (VNF-FG), which describes the NCT and optionally one or more Network Forwarding Paths (NFPs) using those VNFs.
  • VNF-FG Forwarding Graph
  • NCPs Network Forwarding Paths
  • the NVFO is in charge of the onboarding and lifecycle management of a network slice.
  • VNFM VNF Managers
  • the consensual deployment model may lean toward one to one mapping VNFM-VNF.
  • the VIM may perform the actual resource pooling and may interface with an SDN controller to dynamically provision a network slice topology. Besides setting up the NCT, the SDN controller can also act as an SFC
  • Controller 1008 when applying the IETF SFC architecture as shown in Fig. 10.
  • a description of the logical view of the network slice and its VNFs may require a rich language or data model format to express the variety of implementations for particular deployments.
  • an ability to convey QoS policies and associated requirements information is important, in order to provide the breadth of 5G services on the underlying infrastructure as well as achieve the desired performance levels. It is recognized herein that the security of the infrastructure is another important requirement that needs to be addressed.
  • the Topology and Orchestration Specification for Cloud Applications is a file-based template language for deploying portable cloud or telecom services and applications.
  • YAML grammar To describe a service topology template, which specifies the various building blocks (nodes) and their interrelationships and provides links to artifacts (scripts, software packages, reference for VM images etc.) needed during deployment.
  • the TOSCA grammar defines a node type for placement, auto- scaling policies etc. but has left the definition of QoS policies for future normative work.
  • Orchestration should list the slice required QoS Class Identifier (QCI) and Security requirements in the network slice template, and reflect it for the infrastructure portion it will execute on.
  • QCI QoS Class Identifier
  • the orchestration should specify the corresponding selected key metrics/thresholds that the Orchestrator will collect and monitor for possible corrective action in order to continue to meet the expected SLA.
  • ETSI MANO defines placeholders for the service KPIs and monitoring parameters in NSD aka “service_ deployment_ flavor” and “monitoring_ parameter” (without mandating any particular metrics).
  • Such E2E SLA enforcement through Orchestration may enable, for example, fully automated and flexible Network-as-a-Service (NaaS) deployments.
  • SCAP Security Content Automation Protocol
  • SCAP content consists of security checklist data represented in automated XML formats, vulnerability and product name related enumerations, and mappings between the enumerations.
  • the SCAP security checklist data is configuration checklists written in machine readable languages (XCCDF).
  • SCAP checklists have been submitted to, and accepted by, the NIST National Checklist Program. They also conform to an SCAP template and style guide to ensure compatibility with SCAP products and services.
  • the SCAP template and style guide discuss requirements for including SCAP enumerations and mappings within the checklist (see below).
  • SCAP checklists refer to SCAP test procedures (low level checks of machine state written in OVAL). SCAP test procedures are used in conjunction with SCAP checklists.
  • SCAP enumerations are a list of known security related software flaws (see CVE below) and a list of known software configuration issues (see CCE below):
  • CCE Common Configuration Enumeration
  • CVSS Common Vulnerability Scoring System
  • CVSS The Common Vulnerability Scoring System (CVSS) is an open standard for assigning scores to a vulnerability that indicates its relative severity compared to other vulnerabilities.
  • the language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment.
  • Extensible Configuration Checklist Description Format Provides a
  • NIS Network Slice
  • the diversity of business models in 5G introduces the notion of network sharing and a highly distributed and shared infrastructure as a paradigm shift relative to the traditional operator owned and closely guarded telecommunications infrastructure.
  • the diversity of services which include some very security sensitive services and some requiring high reliability and resilience, introduces the need to provide assurances of the security of the infrastructure to service providers as a new requirement for 5G networks.
  • attack can be divided into two categories: active and passive attacks.
  • Active attacks may significantly affect normal network operations since an adversary may attempt to tamper or disrupt network operations through malicious intervention of network operations.
  • Passive attacks do not disrupt network operation, but may be used to later launch an active attack or compromise data security based on information gleaned or inferred.
  • there may be physical attacks on a system or cyber-attacks, which may be carried out remotely.
  • Fig. 8 shows a summary of the possible attacks on legacy and new 5G networks where the vulnerabilities are categorized into physical and cyber.
  • 5G networks face a new set of attacks due to the deployment of new business models such as leasing infrastructure from a large number of potential providers, highly diffused geographic placement of equipment, and technologies such as COTS platforms, Network Function Virtualization (NFV) and Software Defined Networking (SDN). Some of these vulnerabilities are comprehensive and span the whole network. The impact of such vulnerabilities depends on the context of the deployed business model and the service being delivered.
  • a system may be protected in a variety of ways. Broadly speaking, the security protections may be classified into physical and cyber security. Physical security is related to the physical protections and may include use of locks, security guards, access cards, visitor logs, CCTV cameras, secure zones, assessment of the level of training for operators and users and so forth.
  • Cyber security may include use of encryption for data communications and storage, firewalls, virus protection software, access control systems, vulnerability analysis, results of penetration testing and so forth.
  • 5G systems may need to prepare for a wider range of attacks than was necessary for traditional wireless systems.
  • the systems may assess the risks introduced and apply security mechanisms to reduce or mitigate the risks.
  • 5G networks may need to address how much trust can an MNO (or entity that is to use a Slice) have in a 5G Slice to provide a particular service.
  • 5G networks may also need to address a way to quantitatively measure the level of trust in a Slice. Further, the measure may be monitored over time, as it may change over time.
  • Various security requirements are addressed by way of the SPV assessment of a network slice (NS) described herein.
  • NS network slice
  • described herein is a systematic framework and approach that may be used to assess and measure the level of trust (or risk involved with regard to the various deployment models and services to be provided), and to aid secure delivery of the anticipated 5G services through Slices, individual network functions, or traditional network infrastructure.
  • the process for deriving and measuring the level of trust takes into consideration the policy requirements from different stakeholders, for example stakeholder service provider entities, and takes into consideration security attributes that are important to the stakeholder in evaluating the level of trust. It is recognized herein that the latter part may be critically important for 5G networks because much of the infrastructure may be shared and not owned by the operators.
  • NIS Network-related services
  • a working framework around the notion of an assessment of the security of a NS is described below.
  • This assessment is referred to herein as an SPV, which assesses the trustworthiness of a NS and/or level of assurance based on a full 360° security assessment, which includes both physical and cyber security protection mechanisms.
  • Example representations for the SPV are first described, and then an example methodology to derive an SPV based on a variety of security attributes is described. Examples to illustrate these concepts when evaluating an SPV for a NS are also presented.
  • the SPV brings about different opportunities and responsibilities around NIS to the various stakeholders.
  • the SPV enables an asset owner to expose transparently and objectively the security of a NS to various connectivity or partner service providers (e.g., MVNO) as a differentiating feature of their infrastructure offering (e.g., NaaS).
  • MVNO connectivity or partner service providers
  • NaaS infrastructure offering
  • the asset owner may allow these customer/partner providers to drive the SPV derivation according to their own provided policies through standardized interfaces so as to emphasize security attributes that are important for them and deemphasize security properties that are less important.
  • a service provider may select a network infrastructure based on a required level of security that is appropriate to render a particular service.
  • the SPV may be used to fine tune the service level security for the various layers of the network from the Control Plane (CP), User Plane (UP), to the Management Plane (MP).
  • CP Control Plane
  • UP User Plane
  • MP Management Plane
  • Another possible use case is use of the SPV as an enabler for an asset owner to offer multiple possible grades of security (e.g., varying SPV) to various service providers. This may offer opportunities for flexible monetization of the infrastructure security as a tiered offering, which may be further passed on the customers of the service provider(s).
  • the 5G network may need to assess the NIS to be able to select the most trustworthy paths and secure components (including interfaces) at both the RAN and the Core networks such that the Slice security level is matched with the expected delivery of services.
  • the SPV provides a means to obtain an overall security assessment, level of trust or risk assessment for an entity, which may be software, a device, a collection of devices/functions or an entire NS, and a level of confidence that the entity will behave in an expected manner.
  • the measurement of a Slice SPV provides a metric for the level of trust or assurance that the slice will perform as required for the service being provisioned.
  • the SPV may be utilized as a means to enable matching of a service to a NS, where a high SPV would provide a higher level of assurance than a low SPV commensurate with services such as autonomous vehicles requiring ultra-reliable, low latency through to broadband video delivery respectively.
  • the security provided by different slices may vary based on implementation and deployment scenarios.
  • the requirements for different slices may vary based on the type of service being delivered.
  • the SPV of the individual network functions or components that provide the slice functionality may be taken into consideration.
  • Each individual network function or component in a NS network infrastructure may have an SPV based on its security attributes that may be derived by check listing the security capabilities, as shown in Fig. 11, and further described below.
  • Trust-security and validation mechanisms are one of many factors that can influence the SPV.
  • the SPV of a slice is a value that provides an indication of the security level offered by a network slice when utilized as part of an MNO RAN/Core communications network.
  • URLLC a network slice
  • Example appropriate security mechanisms include selecting trustworthy infrastructure components (e.g. NFs), secure paths, and appropriate security features and functions.
  • the SPV of a slice may therefore be taken into account when initializing various types of sessions through a 5G network. More specifically, a measure of the slice SPV may help the network achieve an overall end-to-end (E2E) security for each slice according to the required level of service security per slice, and in an optimized manner.
  • E2E end-to-end
  • Security attributes may be categorized into Physical Security Attributes (PSA) and Cyber Security Attributes (CSA).
  • PSA Physical Security Attributes
  • CSA Cyber Security Attributes
  • An example of a security standard is Common Criteria, which defines increasing levels of security for equipment evaluation.
  • Another example is access control mechanisms, where access to a particular network facility with biometric access may be evaluated to a high security level, whereas a regular magnetic card system may be assessed as a relatively lower security level.
  • Yet another example is devices with a varying number of active accessible physical ports, where the more open unnecessary ports available/detectable, the lower the security level.
  • Some other assessments may require interviewing of security personnel or filling out of questionnaires by security personnel, which address specific aspects of how and what security practices are in place by an organization.
  • some attributes may relate to tamper-resistance, some to an ability to detect physical tampering, some to unauthorized physical access detection, and some to remediation capabilities to name a few.
  • This comprehensive collection of attribute scores may then be exposed and utilized in performing an overall full 360° security assessment of a network function and network as described below.
  • the PSA and CSA associated with a node can be exposed to enable an independent trusted entity to derive the SPV associated with the node.
  • the PSA and CSA that are associated with a given node may be based on an evaluation performed by one or more trusted evaluation entities.
  • best security practices may be related to how an entity or device is configured, used, and managed relative to what would be considered as appropriate procedures and processes.
  • the attributes related to best security practices may be based on industry endorsed security best practices for devices, and whether they are incorporated and applied to a device.
  • a system or device may be configured with security mechanisms, such as encryption and secure tunnels, etc., but if these features are not configured or utilized using best practices security then weakness in the overall system may be introduced.
  • use of weak keys or default manufacturer provisioned keys implemented in an otherwise well engineered security system can introduce various security vulnerabilities and lead to on overall weak system which may be easily hacked.
  • Network facilities should have adequate physical security to prevent unauthorized access to network entities.
  • Example physical security measures include controlled access to premises, use of security guards, access cards, visitor logs, CCTV cameras, secure zones, etc.
  • network components may be placed in a secure zone where it is hard to gain fraudulent access.
  • secure zones may include areas such as a data center operations center, etc.
  • Each of the above measures or PSA may be assigned a value depending on how well the protections are provided.
  • the assessment of a CSA score for cyber security may include the list of attributes, which are closely related to the cyber security aspects of a system (non-physical or people oriented) such as communications links, use of cryptographic keys, security firewalls etc. These are discussed further below. It will be understood that the list of attributes is presented for illustration purposes and is not intended to be an exhaustive list.
  • Assessment of compliance to policies, procedures, and processes may be carried out by an audit process with a vulnerability assessment. For example, in some cases, compliance with well-established Security Policy standards (e.g., ISO 27002: Information Security Policies, NIST Information Security Policies, Common criteria, FIPS 140-2 for cryptographic modules) may be assessed.
  • Security Policy standards e.g., ISO 27002: Information Security Policies, NIST Information Security Policies, Common criteria, FIPS 140-2 for cryptographic modules
  • risk values which are results of system audit(s) may be based on the different types of risk assessment techniques that may have been carried out combined with the results of each of the assessments.
  • the risk assessment techniques can be qualitative, quantitative, or semi-qualitative.
  • risk identification sources of risk, areas of impacts, events (including changes in circumstances), and their causes and their potential consequences are identified.
  • risk analysis may involve developing an understanding of the risk. Risk analysis may provide an input to risk evaluation and to decisions on whether risks need to be treated, and on the most appropriate risk treatment strategies and methods. Risk evaluation can assist in making decisions, based on the outcomes of risk analysis, about which risks need treatment and the priority for treatment implementation.
  • the various testing may be carried out, for example and without limitation, vulnerability testing and penetration testing.
  • Vulnerability testing may determine the vulnerability of protocols, algorithms, and implementations of those protocols and algorithms.
  • Part of the vulnerability testing may involve scanning for applications and open ports, searching for application-specific vulnerabilities (e.g., Microsoft vulnerabilities), as well fuzzy testing, in order to determine vulnerabilities to inputs containing invalid, out-of-bounds, and random data.
  • Penetration testing refers to testing in which the system entities are more deeply analyzed.
  • Custom software may be developed and used in order to exploit the vulnerabilities.
  • privilege escalation may be carried out after which the system may be hijacked.
  • Ratings may be computed in the form of qualitative (or quantitative) values such as, for example and without limitation: Low (1-3), Medium (4-6) and High (7-10).
  • the ratings may have been compiled and boiled-up from individual vulnerability risk values to a value that is an approximation of the overall risk rating.
  • risk assessment may take into account both standard and contextual information for a more accurate computation of risk.
  • Contextual information may include time / day / date, geographic location, usage scenario (high exposure or low exposure), etc.
  • CC Common Criteria
  • ISO/IEC 15408 the stake-holders of a certain entity or component
  • SFRs and SARs security functional and assurance requirements
  • PPs Protection Profiles
  • EAL Evaluation Assurance Level
  • SARs security assurance requirements
  • Common Criteria lists seven levels, with EAL 1 being the most basic (and therefore cheapest to implement and evaluate) and EAL 7 being the most stringent (and most expensive). Higher EALs do not necessarily imply “better security", they only mean that the claimed security assurance of the TOE has been more extensively verified.
  • attestation provides a means to assess the security state of a platform, software/middleware and data stored and used on a system and provides a means to verify the integrity of a platform. Attestation can be carried out as a static assessment, for example, when a system is powered on and started and supplemented with dynamic attestation, over time, during system operation.
  • the attestation may take on values of assurance from low to high and an initial static attestation may become stale or decay over time if not checked often or frequently enough relative to changes in the system configuration.
  • Attestation of a network component may be performed using various supporting mechanisms, for example and without limitation, 1) Trusted Platform Modules (TPMs) to perform hardware, firmware, software and data attestation; 2) Virtual Trusted Platform Modules (VTPMs) to attest Virtual Machines (VMs); and 3) Secure or trusted execution environment hosting an attestation agent.
  • TPMs Trusted Platform Modules
  • VTPMs Virtual Trusted Platform Modules
  • VMs Virtual Machines
  • Secure or trusted execution environment hosting an attestation agent for example and without limitation, 1) Trusted Platform Modules (TPMs) to perform hardware, firmware, software and data attestation
  • VTPMs Virtual Trusted Platform Modules
  • VMs Virtual Machines
  • Secure or trusted execution environment hosting an attestation agent for example and without limitation, 1) Trusted Platform Modules (TPMs) to perform hardware, firmware, software and data attestation
  • VTPMs Virtual Trusted Platform Modules
  • VMs Virtual Machines
  • static attestation takes different security scores depending on the level of attestation. More particularly, for example, the scores may depend upon various attributes, such as the type and number of attested software components, the protocol used for attestation, and the strength of the TPM cryptographic process and the security rating of the TPM module.
  • dynamic attestation involves continuous assessment over time of a network component, which may change over time and is bound to an initial static attestation which may occur when a system powers up or boots up. Attestation is critical for 5G networks deployed using NFV as a key enabler since the core functionalities are implemented in cloud servers and where VNFs from different networks may share the same platform as tenants.
  • a VNF can migrate from one platform to another according to the resource allocation policies that are applied in the Management and Orchestration entity (MANO). These migrations need dynamic attestation over time to provide assurances that the VNF is being carried out on an attested and secure platform.
  • a VNF when instantiated on a VM platform creates a VNF Instance (VNFI).
  • VNF may be instantiated on one or more VMs, creating a VNF Component Instance (VNFCI).
  • the host system refers to the underlying infrastructure, such as the servers and underlying hardware, firmware, software and data components, through to the Virtual Machines (VMs) or container support.
  • the tenant system may refer to the functions running on VMs and containers.
  • the Data Security set includes various attributes, such as, for example, security of data-at-rest attributes, data-in-transit attributes, and credential management for data security attributes.
  • Data Transmission data-in-transit
  • An attacker can compromise data during transmission of the data.
  • an attacker can introduce a vulnerability to the entire network. Therefore, in some examples, data is cryptographically protected during transmission to achieve confidentiality, integrity, non- repudiation, and loss detection.
  • Different cryptographic schemes e.g., TLS / DTLS with public or symmetric keying
  • TLS / DTLS with public or symmetric keying can provide different levels of security for data- in-transit.
  • Credential Management protecting and cryptographically separating keys and keying material of the security protocols is required, in some cases, in order to maintain the security of data-at-rest and data-in-transit.
  • the characteristics that may be taken into consideration for rating credential management attributes may include the credential exchange protocol (e.g., TLS), mechanisms used for storing the credentials securely, credential generation algorithms, the strength of generated keys, etc.
  • Protection mechanisms may refer to types of combinations of mitigation mechanisms that may be used for the general protection of the infrastructure, network, devices, virtual functions, and applications from various types of denial-of-service attacks.
  • Example types of denial-of-service attacks include flooding attacks and malware-driven attacks from outside the user-side or from other networks (inter-network). Protection mechanisms may also be used for protecting critical infrastructure of the service provider from insider attacks (malicious or non- malicious).
  • Example types of protection mechanisms include the use of Demilitarized Zones (DMZs), Firewalls (FWs) and Intrusion Prevention Systems (IPS), Access Control Lists (ACLs), and Virus Protection. Example protection mechanisms are now further described.
  • a DMZ may refer to a physical or a logical subnetwork that enables the secure exposure of certain network external-facing services to a larger and untrusted network, usually the internet.
  • DMZs can be with a single firewall or dual firewall.
  • Firewall features can be designed to prevent unauthorized external individuals from gaining access to a network (virtual or physical), and to block attacks on the network, while at the same time allowing authorized users to access network resources.
  • the level of security provided by a firewall may depend on the configuration of the firewall. Security features of a given firewall may be customized. For example, different types of ACLs provide multiple levels of security. Example ACLs include basic ACLs (standard or extended), Lock-and-Key ACLs, Reflexive ACLs, Context-based ACLs, etc.
  • configuring the firewall as an Intrusion Detection System may identify the most common attacks using "signatures" to detect patterns of misuse in network traffic.
  • Firewall is general terminology that may be used to refer to intrusion detection as well as intrusion prevention mechanisms.
  • Application Level Gateway (ALG) functions e.g., application-proxy such as SIP ALG
  • SIP ALG application-proxy
  • the rating of the protection mechanism used may increase when a network provider uses an IPS along with a robust firewall.
  • the rating may be lower if only a firewall is used, provided the used firewalls are of the same type.
  • Virus Protection is affected by different factors including, for example, supported viruses list, viruses list update, etc.
  • the AV protection is provided as a host-based protection mechanism and plays a complementary role to firewall/IPS.
  • ratings for various AV are provided by well-known malware analysis organizations.
  • the origin of the protection mechanism used may be taken into account when the ratings (e.g., SPVs) are being computed.
  • protection mechanisms e.g., Kaspersky anti-virus
  • Kaspersky anti-virus may have close ties to a foreign government, which may negatively affect their ratings.
  • Data Provenance refers to an audit system that records network logs and events. Mechanisms used for logging may be rated, in accordance with various example SPV computation.
  • Prevention may be rated by an audit process or may be provided by the software or application that may have been used to provided such protection mechanisms.
  • a SPV which may also be referred to as an SPV score, without limitation, may be used by various stakeholders (e.g., Connectivity Providers, Partner Service Providers, third party Application Service Providers) to assess the security of a network.
  • stakeholders may assess the security of a network according to their own, possibly proprietary, evaluation criteria.
  • it is recognized herein that it may be desirable to apply standardized means of deriving the underlying information elements, so as to leverage standard industry practices in performing a security assessment of the underlying components (e.g., NF) that comprise a system such as a network slice (NS).
  • NF network slice
  • stakeholders may wish to apply different rules in order to derive the SPV of a network entity or function based on their specific policies and service requirements.
  • these stakeholders may wish to compare and contrast the security levels of different network infrastructures (e.g., from different asset owners or infrastructure providers) based on their own specific security level evaluation criteria.
  • These custom, stakeholder specified policies and rules may capture how an aggregate SPV score is derived based on the evaluation of the fundamental attribute scores (CSA, PSA).
  • the attribute scores may be uniform across different network entities/infrastructure based on industry established standards and methodologies (e.g., Common Criteria).
  • the derived SPV score may therefore vary between one stakeholder and another based on applied polices and rules, even for the same underlying network function and attribute scores.
  • an independent trusted entity may derive the SPV.
  • the CSAs and PSAs security attribute scores related to the NF may be assessed. Then, these PSAs and CSAs may be combined using a set of rules that are designed by the service provider or operator (e.g., MNO) in order to compute a final SPV value.
  • a first pass at assessing the security of a NF may be performed based on a 4-tuple based SPV representation around the various classes of security attributes, such as, Physical Security, System Security, Data Security, and Protection Mechanisms.
  • the set of rules that aggregate the SA values of different attributes may be influenced by each Service Provider (e.g., MVNO) according to appropriate business models, which in turn can be used to create the appropriate set of policies, which then may be realized by means of well-established and tested standards.
  • MVNO Service Provider
  • NF Rules is then used to combine and aggregate the System Security, Physical Security, Data Security, and Protection Mechanisms SCASs into a single SPV score for the NF.
  • the Class Attribute Rules and NF Rules may represent a set of rules that determine the level of importance for each of the security attributes when evaluating an SPV value for a given NF.
  • a default set of rules may be established by an MNO or NS owner, and a service provider (e.g., MVNO) may elect to modify or tailor the set of rules based on their own unique needs.
  • MVNO MVNO
  • This example mechanism allows a given service provider to impose their own policies into the SPV evaluation function. This accessibility to a service provider may be critically important, in some cases, because it emphasizes a virtual "Ownership" model that complements the spirit of NFV and use of virtualization technologies for the realization of 5G networks.
  • one MVNO may have a summation rule where the operator sums up a plurality of critical CSAs and PSAs attributes, and then normalizes the sum to the total number of CSAs and PSAs to produce a single SPV score.
  • another MVNO may weigh each set of CSA and PSA attributes and give scores for each CSA/PSA based on the criticality of a given attribute to the assessed type of slice.
  • the SPV metric representation of a given NF may take different forms based on the level of granularity required to manage or expose the security attributes as presented herein (PSA, CSA). Out of the possible full spectrum of SPV, example options are presented herein for illustration purposes, though it will be understood that SPVs may be alternatively computed.
  • the SPV for a slice itself may be a combination of the SPV of its constituent NFs, which may offer different granularity levels.
  • these different forms of SPV are not mutually exclusive and different entities managing SPV throughout the system can use any one of these representations depending on their respective role in the network and the actions they perform (e.g., SPV calculation, exchange, storage, etc.). Furthermore, each service provider or network operator may wish to apply their own rules and polices in deriving the SPV of a NF, and ultimately a NS.
  • this may be the most detailed view of an SPV represented by an exhaustive list of all the scores for each and every individual PSA/CSA security attribute.
  • this type of representation may be required for a security management function within a network that may be in-charge of monitoring, or for providing/computing the SPV of network elements (e.g. used for security audit purposes).
  • a 4-tuple based SPV may represent a middle-of-the-road representation between the scalar and the fined grained SPV.
  • the security attributes scores of a network entity may be collapsed at a security class attribute level (e.g. Data Security under PSA and CS A) into a tuple of values.
  • an SPV could be expressed as a 4-tuple (vector) representing the values for Physical Security, System Security, Data Security and Protection Mechanisms.
  • the SPV [Low, Medium, High, High]
  • / 1 , 2, 3, or 4, which represents each of the four classes of security attributes: Physical Security, System Security, Data Security, and Protection Mechanisms.
  • This scalar representation may offer a simplified and abstracted view of network security attributes. It may offer a straightforward way to convey a very high level security requirement or assessment about a given NF.
  • a user e.g., an application on UE or a Server
  • the network may interpret this as a requirement for high Data-Security and protection (e.g., security for data-in-transit and data-at-rest).
  • this SPV requirement may translate into high System Security, high Data Security, and High Physical Security scores as well.
  • the scalar representation may be too coarse for some applications that require more granular NIS preferences.
  • the assessment of an SPV may be carried out as a static assessment, for example, when a system is configured or powered on and started or dynamically, over time, during system operation. If a security attribute never or rarely ever changes with time then it may be sufficient to perform a static assessment. However, in some examples, if a system component is likely to change over time then the SPV may need to also be performed dynamically over time so as to ensure that any changes are captured.
  • a static security attribute may never change or may change very infrequently with time and so an initial assessment may suffice to capture the assessment.
  • some security attributes may be associated with the manufacturer of a component (such as an EAL level certification) or configured by a service provider during commissioning and provisioning and some security attributes may be assessed based on industry endorsed security best practices and whether these practices are incorporated into the component and used.
  • An example of security best practices is the "OWASP Top 10 list”.
  • a dynamic assessment of an SPV may be required for security attributes that change more frequently with time and a static assessment becomes stale over time and inadequate to represent the state of an assessment.
  • security attributes include IP address, time (of access), and location.
  • the assessment may be carried out on a continuous basis and at a configured frequency of sampling or may be event based, for example, when a component software configuration changes.
  • an example system 1200 includes a Security Management Function (SMF) 1202, a Posture Collection and Aggregation Function (PCAF) 1204, a plurality of Validation Functions (VFs) 1206, and a Posture Target (PT) 1208.
  • SMF Security Management Function
  • PCAF Posture Collection and Aggregation Function
  • VFs Validation Functions
  • PT Posture Target
  • the example system 1200 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure.
  • Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Figs. 12A and 12B, and all such embodiments are contemplated as within the scope of the present disclosure.
  • the system 1200 performs triggering, conducting, and reporting of Security Posture Assessments.
  • the SMF 1202 may initiate the posture assessment process. Triggers that initiate the posture assessment process may be initiated periodically based upon certain policies, based upon a service access request, dynamic SLA negotiation, etc.
  • the PCAF 1204 is responsible for identifying the request from the SMF 1202, and then initiating the various security Validation Functions 1206.
  • the PCAF 1204 may aggregate the results from the various validations and create an aggregated posture assertion.
  • the Validation Functions 1206 may be functional entities that perform physical security audits, vulnerability assessments, platform validations, etc.
  • the functionalities 1206 may be co-located or distributed. Further, in some examples, the Validation Functions 1206 may belong to different administration domains.
  • the PT 1208 may be a network function (NF), which may be a physical NF or VNF. In some examples, the PT 1208 may be any entity whose posture has to be assessed.
  • the PT 1208 may be part of a routing fabric (e.g., IRF), physical hardware, servers, network functions, and applications.
  • the PT 1208 may also include servers and network functions that may be virtualized (VNFs). Further, the PT 1208 may be a collection of routers/s witches, NFs, VNFs, servers, and applications that make up a physical network or a virtualized network (e.g., network slice).
  • the SPV assessment system/entities described herein may be realized in the network architecture that was described with reference to Fig. 5.
  • the SPV nodes may be specifically mapped to the MANO functional blocks, for example, when dealing with VNFs or a traditional OSS/Element Management System (EMS) architecture when legacy functions are utilized.
  • EMS Simple OSS/Element Management System
  • the SMF 1202 is co-located/runs in the operator OSS (not shown in Fig. 5).
  • An SPV assessment may, for example, be triggered by a new network service instantiation.
  • the PCAF 1204 may be co-located/run in the NFVO 406.
  • An SPV assessment may be requested by the SMF 1202 via the Os-Nfvo interface.
  • the request may be scoped to a single VNF 408 or for an entire VNF-FG.
  • the PCAF 1204 may break down the request to as many requests as required, dispatch the requests to the various VFs, and ultimately aggregate the returned results on behalf of the SMF 1202.
  • the PCAF 1204 executes an assessment of the network function according to the policies provisioned or provided by an external stakeholder, such as an MVNO or service provider, wishing to deploy a network utilizing the underlying network infrastructure components.
  • the PCAF 1204 may provide a unified interface to enable the SPV determination policies to be specified by a variety of different external stakeholders.
  • a VF 1206 may provide assurances to a VNF 408, and may be distributed in both the VNFM 506 in charge of that VNF 408, and the VIM 508 in charge of the NFVI 402 where it is to be executed.
  • the VF 1206 may provide a unified Application Programming Interface (API) interface to the PCAF 1204 in order to expose the security attributes of the infrastructure functions for further processing and assessment.
  • API Application Programming Interface
  • the VNFM 506 may handle the request from the PCAF 1204 via the Or-Vnfm interface by requesting remote attestation results from its VIM 508 co-located counter-part via the Or-Vi interface.
  • the VIM co-located VF may perform static and dynamic attestation of the VM associated with that VNF, as well as of the host running that VM via the Nf-Vi interface.
  • the VF 1206 may expose the various security attributes of the underlying function to the PCAF 1204.
  • both the SMF 1202 and PCAF 1204 may be co-located in the OSS 504 and collect assessments from various VFs distributed in their respective vendor specific Network Management System (NMS) and/or EMS.
  • NMS Network Management System
  • EMS EMS
  • the PTs 1208 are the Network Elements (NE), for example, legacy network appliances with integrated hardware and software.
  • the SMF 1202 may be triggered to perform security posture assessment by certain management functions based upon certain conditions.
  • the triggers may be policy-driven and, for example, may be based upon time / day / date, frequency of assessments required, certain other conditions such as SLA establishment, access control requests, etc.
  • the SMF 1402 initiates a Posture Request message that may contain one or more parameters associated with an identity of one or more posture targets (PTs) 1208.
  • Other parameters in the message may indicate the type of validation requested, posture attributes, and optionally the posture attribute format.
  • An Entity-Id[] parameter may contain one or more addresses of PTs and may be represented as one or more IP addresses, URLs of the resources, sub-network addresses (e.g., consisting of more than one IP addresses), MAC addresses of the entities (e.g., MAC addresses of switchesAViFi Access Points) or identities of virtual machines (e.g., VNF-Id(s)).
  • a ValidationType[] parameter may indicate the types of validations (e.g., physical security, vulnerability assessment, platform validation etc.).
  • a ReqPostureAttr[] may be an optional attribute list and may contain specific posture attributes (e.g., numerical value that represents posture, presence of protection mechanism such as anti-malware functionality, robustness of the anti-virus functionality, etc.). Additionally and optionally, AssertionFormat[] parameter(s) may be included that describe the type of format (e.g. signed certificate vouching for the security posture) for each type of validation that may have been performed.
  • the PCAF 1204 interprets the Posture Request message and parameters contained in the request, and determines the communication addresses of the entities.
  • the PCAF 1204 also determines detailed validations that may have to be performed, and the interpretation of the associated posture attributes that may have to be requested.
  • the PCAF 1204 may send a separate Validation Request to each one of the VFs 1206.
  • the parameters contained within the request message may contain a request for posture attributes within ReqPostureAttr[] parameter(s) and optionally type of format(s), represented as AttrFormat[] that is expected for each of the associated posture attribute(s) results, represented within each.
  • a validation request may be sent from the PCAF 1204 to a first VF 1206 (VFl) that may perform Platform Attestation.
  • VFl first VF 1206
  • VF2 second VF 1206
  • the VFl performs a remote attestation of the PT 1208.
  • the PT 1206 may be composed of one or more network entities (functions, hardware, applications, etc.). Therefore, the VFl may perform an assessment per network entity. If the entities are made up of virtualized functions, then, in some cases, only functional assessments are performed.
  • the first VFl uses a CCE 1210 in order to create platform validation and configuration tests. The first VFl initiates the validation process and requests ReqPostureAttr[], attributes that may be used for performing the validation.
  • the second VF2 uses CVE 1212 in order to create vulnerability assessment tests and initiates the validation (vulnerability assessment process).
  • the ReqPostureAttr[] carries attributes that may be used for performing the vulnerability assessment. Further, other validations (e.g., physical security) may be initiated in a similar manner.
  • validation results are obtained from the PT 1208 in the form of ResultPostAttr[] .
  • the results carried may be in the form of raw parameters (attributes) with associated scoring values similar to CCSS.
  • the results, ResultPostAttr[] may be represented in the form of CVSS values or may provide detailed values.
  • each of the validation functions 1206 provide a validation response to the PCAF 1204.
  • the AssertionAttr[] may carry digitally signed posture values that represent the ResultPostureAttr[].
  • the PCAF 1204 may aggregate the ResultPostureAttr[](s) from the VFs 1208 and send aggregated results to the SMF 1202.
  • the SMF 1202 may create a scalar value that represents the SPV of the entire PT 1208, which includes the PSA and CSA components.
  • the SPV may also be presented in the form of a vector as described earlier herein. This SPV representation may be digitally signed by the SMF 1202 using its private key, and published to various entities that may use the SPV for access control, slice negotiation, SLA negotiation etc.
  • a NS is composed of a number of NFs each interlinked to provide an overall NS function. So in order to establish an SPV for a NS, the SPV of the individual components may be taken into
  • the SPV of a network slice can be viewed as a function of the SPV of its constituent NFs.
  • SPVNS NS Rules (SPVNFI, ... , SPVNFK)
  • the "NS_Rules ()" may be a set of instructions and/or calculations on the SPV scores for the list of NFs that compose the NS.
  • the rules provide a flexible means of determining a NS SPV, and allow different service providers to influence the derivation of an SPV based on their own specific policies and business requirements.
  • the rules may produce a monotonically increasing SPV, such that a high SPV indicates a higher level of trust than a low SPV.
  • the rules may be specified by a service provider wishing to utilize a NS, and may capture policies to be specified by the service provider.
  • the result of applying the rules may produce a scalar NS SPV value, which may be used to specify security requirements for a NS, such as the minimum SPV value for a NS to be used for a particular service.
  • NF SPV evaluation As described above for a NF SPV evaluation, different service providers may provide different custom defined rules for instance different evaluation criteria or formulae, in order to aggregate NFs PSA/CSA values or constituent NFs SPV according to their own specific policies. In some cases, the derived NS SPV score may therefore vary between one stakeholder and another based on applied polices and rules, even for the same underlying infrastructure and attribute scores.
  • two connectivity providers may hypothetically apply different weights to the same attribute scores for the same network infrastructure and arrive at different aggregated scores.
  • One of the stakeholders may require a relatively higher reliability from the network infrastructure to run the service and may therefore assign a different emphasis/ weight to the attributes that relate to system integrity, to arrive at an overall different SPV score that reflects the particular requirement.
  • the SFC can be used as an enabler for utilizing an SPV for the individual NFs within a Slice to navigate a communication path based on NF SPV values. This can be accomplished through logging the SPV requirements for each NF, in a chain as part of the SFC definition that is appended to a packet to be communicated, for example, using the network services header (NSH).
  • NSH network services header
  • an SPV for a NF may be represented as a 4-tuple security class attributes (described in more detail herein).
  • an SPV for a NF may be represented as fine grained NF security attributes (described in more detail herein).
  • an SPV driven SFC can be realized using an end-to-end or hop- by-hop approach.
  • identical VNFs VNFla, VNFlb and VNFlc
  • VNFla, VNFlb and VNFlc have different SPV assessments for a particular NS.
  • geographic location may be an important security consideration for certain services to be provided through a NS.
  • a NS based on NFs situated in the USA may have a higher SPV value than identical NFs situated in another country (e.g., a country that might not be part of a treaty that agrees to follow certain security standards/best practices such as common criteria).
  • an SDN controller programs a SC 1302 (e.g., ingress switch/router in Fig. 13) with a particular network
  • the SC 1302 maps incoming traffic flows into a particular network path (e.g., SFP) based on an actual measured or assessed SPV for individual NFs and the required SPV for those NFs, which may be sourced from a management entity such as the SMF.
  • the measured or assessed SPV may be obtained from a trustworthy entity or the assessment may be performed by the network operator.
  • Forwarding rules may be installed by the SDN controller in the intermediate switches (SFF 1306a, SFF 1306b, and SFF 1306c), which steer incoming traffic flows accordingly toward the appropriate NFs or next switch in the path.
  • a node may determine the network configuration, which may include a chain of nodes from the node, through a second node, to a destination node.
  • the node may obtain a security posture value associated with the second node. Further, in an example, the node receives a data packet, and obtains a security posture level requirement associated with the data packet. The node may determine whether to forward the data packet to the second node, based on the security posture value associated with the second node. In some cases, the node forwards the data packet to the second node when the security posture value is sufficient relative to the security posture level requirement associated with the data packet. Further, determining the network configuration may include identifying one or more network paths for incoming packets across a SFC.
  • an SFP may be established once from a central point (SDN controller and ingress SC 1302) within an SFC domain. In some cases, this may be particularly suited to an environment in which changes in the SFP are not frequent (e.g., due to NF movement, failure, decommission, SPV variation) and is also more
  • an SPV based SFP routing using NSH may involve the ingress SC 1302 performing initial classification and NSH insertion into an incoming packet, and various SFFs 1306 in the chain performing lookup up of the SPI/SI in the NSH to determine the Next Hop (NH).
  • the next hop can be one or more NFs 1304, the next SFF 1306, or the end of the path. If the lookup returns multiple possible NFs 1304, then the SFF 1306 may compare their respective measured SPV (e.g., from SMF) with the required SPV that is carried in the NSH (e.g., in the optional variable length metadata field), so that the SFF 1306 can select the best matching NF 1304 accordingly.
  • a first node may determine a plurality of next hops from the first node that are sufficient relative to the security posture requirement associated with the data packet.
  • second node to which the packet is forward is identified as one of the plurality of next hops.
  • a first node may determine whether to forward a data packet to a second node by extracting a network services header from the data packet, identifying the security posture level requirement in the network services header, and determining whether the security posture value associated with the second node is equal to or greater than the security posture level requirement associated with the data packet.
  • the security posture value which may provide a trust metric corresponding to an overall level of trust in the second node, may also be derived based on policies of one or more stakeholder service provider entities.
  • the first and second nodes described in the example above may be network functions within a network slice or virtualized network functions, and the network over which the nodes communicate may be a network slice comprising a plurality of network functions.
  • the first node is an independent trusted entity.
  • the physical and cyber security attributes associated with the second node are exposed to enable the first node to derive the security posture value based on the physical and cyber security attributes.
  • the physical and cyber security attributes associated with the second node are based on an evaluation performed by a plurality of independent trusted evaluation entities.
  • a new NSH header may be inserted (e.g., by an intermediate SC that co-resides with a NF), thereby allowing for highly dynamic and fine grained policy-driven traffic steering. In some cases, this may be especially important when considering life-cycles for VNFs that are much more dynamic by nature than traditional NFs, which implies a potentially more volatile SPV that requires continuous evaluation while deployed.
  • a VNF may be automatically scaled, replaced, or moved in real-time by an orchestration platform with possible security implications (e.g., reduced SPV). This hop by hop approach, with its ability to evaluate and maintain on-the- fly the SPV for any given chained NF, allows for quick incremental SPV
  • Table 9 illustrates an example flow forwarding table for an example hop by hop SPV driven routing applied to the SFC/SFP from Fig. 13.
  • the forwarding data snapshot presented is from the perspective of the SFFs 1306 in charge of forwarding to their respective NF 1304 and next SFF 1306 in the SFP.
  • An example is detailed below in which a packet flows through SFF 1306a, which is the first hop after the SC 1302.
  • the required SPV read from the NSH is HIGH and therefore the next action for the SFF 1306a is to forward the packet to the VNFla whose SPV is also HIGH.
  • the SPV values shown here are qualitative/scalar but may alternatively be composite values (e.g., 4-tuple as previously mentioned).
  • the required SPV is updated with a new value of MEDIUM for next VNF selection.
  • the new SI 253 points to SFF 1306b as the next hop.
  • the new SPV may be LOW from that VNF, which is not applied for the next switch (SFF 1306b) and remains unchanged for SFF 1306b to process.
  • the packets may continue to hop through the SFFs and NFs until it gets out of the chain, where SFF 1306c may strip out the NSH.
  • a Service Description Document describes the types (e.g. HD-Video) and/or characteristics (e.g., latency, throughput, etc.) of services requested or provided by a network slice.
  • the SDD may contain corresponding QoS class Identifiers and/or SPVs.
  • the application/UE may send an SDD to the network.
  • this SDD contains the package of services requested by the user.
  • the SDD may enable an application or a UE to provide information (e.g., non-granular or detailed information) concerning the service characteristics (e.g., QoS requirements and/or security) of the application, to a SN.
  • the SDD may separate attributes into different service planes (e.g., CP, UP, and MP) as shown in Fig. 14.
  • security metrics are added to the SDD as a matrix describing the SPV values for the various NIS attributes (e.g., cyber- security, physical security, etc.) and hence define the requested level of security for each of the services included in the SDD. It should be noted the matrix may be reduced to a scalar value using certain weights for each of the different NIS attributes. These SPV values can be minimum values indicating the minimum acceptable level of security, or a range of security values.
  • Fig. 14 shows an illustrative example for the expected difference in the SPV values for different slices according to the services rendered by each slice.
  • 'n' services may each include up to 'p' QCI values.
  • each of the services may have associated QCI NIS values (1-4) that take into consideration the NIS attributes, (represented as QCI-1NIS1, QCI-1NIS2, QCI-1NIS3 and QCI- 1NIS4 for Service 1).
  • the values may be qualitative (e.g., Low to High) or quantitative (e.g., 1-10) or by any other means which can be interpreted in a meaningful manner by the SN.
  • Fig. 14 illustrates an example of possible security
  • Security-as-a-Service another example approach is to request Security-as-a-Service. More clearly, different levels of security services may be offered by the network, which may be explicitly requested by a UE/application. As an example, an
  • UE/application may request a service denoted as "High Security”, which may imply that the UE/ application requires “malware detection and mitigation” service.
  • an UE/application may only request for "Medium Security,” which may imply that the UE/application just requires only “malware detection” feature.
  • a "Security" service is defined that has its own set of associated QCI values.
  • Examples of Security-as-a-Service may include services such as Credential Management, Identity Management, Secure Connections establishment, Platform Validation, Anti-malware checks or any other mechanisms that may enhance the security of the UE. It may be possible that a UE/application requests for "Service 1" and "Security" as services bundled together. Policies associated with usage of Security-as-a-Service may be provisioned to the UE/application, in order that services may be bundled together.
  • a node or apparatus determines an aggregate security posture value associated with the network, and a required security posture level associated with the apparatus. The apparatus may further determine whether to access a service provided by the network based on comparing the aggregate security posture value with the required security posture level. In some examples, when the aggregate security posture value is sufficient as compared to the aggregate security posture value, the apparatus accesses the service provided by the network
  • the SPV concept and assessment approaches described herein may be applied to a variety of service provider scenarios from the infrastructure of an application service provider, for example a social networking service or an enterprise customer or a bank, through to a communications network service provider's infrastructure, for example an MNO or hot spot service provider.
  • an application service provider for example a social networking service or an enterprise customer or a bank
  • a communications network service provider's infrastructure for example an MNO or hot spot service provider.
  • SPV evaluation for an MNO in order to illustrate how the computation of SPV may be carried out for a NS using the security evaluation principles described above, it is shown how the SPV of individual NFs may be computed based on MNO provisioned policies, and then how these may then be used to determine the overall Slice SPV, either as an aggregate Slice SPV or used as part of each of the VNFs within an SFC.
  • MNOs For a network function, two MNOs, Verizon and T-Mobile, are considered by way of example.
  • Each of the MNOs have their own legacy network as shown in Fig. 16. Moreover, they may slice a part of the core network or the RAN network or both depending on the needs for different slices based upon use cases. Also, some of the RAN or the core components in the slice may be leased or shared with another MNO or a third-party entity, for example, depending on the business model that is adopted by each MNO.
  • both MNOs have the exact same network architecture as shown in Fig. 16.
  • Some of the components are remotely located geographically (e.g., S-HSS/HLR in the URLLC Slice), and thus not in the same infrastructure location.
  • the infrastructure components are shared (e.g., shared hardware) by more than one MNO, (e.g., VNFs such as P-GW, ePDG) and the list of infrastructure security features for each of the slices are shown.
  • SPV computation rules may aggregate weighted attributes as follows:
  • SPV w L 3 ⁇ 4: 1 (w w M s£. ⁇ )
  • SPV ⁇ 18 the SPV of the j th security attribute in the ith security class attribute
  • Mi is the total number of attributes needed to be assessed in security class attribute i
  • wy is the weight accompanied with each of the attributes based on the criticality of that attribute from the MNO perspective (Verizon or T- Mobile).
  • a weighted aggregation computation for each security class attribute is accumulated and w'set is the weight of each security class attribute i according to policies set by each MNO.
  • i e [1,4] represents the four security class attributes that are considered in the example, i.e. physical security, system security, data security and protection mechanisms.
  • Verizon and T-Mobile adopt different policies and scoring systems as shown in Table 11 and Table 12 below.
  • infrastructure security may be of higher priority for T-Mobile than for Verizon and thus the former may place a higher weighting for Physical Security Class Attributes.
  • Verizon may rely on sharing the RAN/Core network with other MNOs more commonly than T-Mobile.
  • T- Mobile may own dedicated physical network functions and devices, and so Verizon may place a relatively higher weighting for certain class attributes, such as System Integrity and Data Security Class Attributes.
  • the other class attributes can be weighted according to the MVNO's network planning, ownership, and business model.
  • the scores assigned in Table 11 and Table 12 may be based on analysis of the PSAs and CSAs detailed herein. By way of illustration for the example, the following conventions and scoring system is utilized, which is summarized in Table 10, though it will be understood other scoring systems can be implemented as desired:
  • Static attestation score may take a value that ranges from 1 (no attestation) to 10 (high integrity).
  • Dynamic attestation score may take a value that ranges from 1 (no dynamic attestation) to 10 (strong dynamic attestation).
  • the credential management ratings are assigned from 1 (weakest) to 5 (strongest) based upon the characteristics and criteria described above.
  • the use case scoring criteria for each of the MNOs: the Weight (w) of the attribute and the individual score of the attribute (Attr Scoreij).
  • the derivation of the Attr Score is consistent across different types of infrastructure while the weights may change with different MNOs as well as different use cases based on policies.
  • the set weight controls the net SPV of a NF according to the policies specified by the MNO.
  • aNF used to construct a URLLC slice may be selected or configured such as to expose a relatively higher score for those attributes than an equivalent when used in an eMBB slice.
  • an end result is obtained, which includes a net SPV for a given NF that may vary across MNOs and use cases, reflecting the varying security requirements across MNOs or use cases (for e.g., a higher net SPV for URLLC than eMBB use case for both MNOs).
  • Table 11 Example SPV Evaluation for eMBB Use Case for Verizon and T-Mobile
  • Table 12 Example SPV Evaluation for URLLC Use Case for Verizon and T-Mobile
  • SPV Evaluation for a Network Slice an example is now illustrated of how the SPV for the NS can be computed from a User Plane (UP) point of view.
  • the evaluation example illustrated here for the UP can be applied respectively to the Control Plane (CP) or Management Plane (MP) NFs to derive the CP or MP SPV of a NS.
  • CP Control Plane
  • MP Management Plane
  • the Slice SPV score may computed as follows:
  • the NS SPV can be maintained as a vector of NF's SPV values, such as those captured in Table 13 for example, to enable an SPV-based SFC.
  • an inventory of the components (logical or physical) involved in setting up the NS may be established as per the tables listed above. Once an SPV of all components is determined, it can serve as a baseline for incremental (re-)evaluation while in operation (runtime).
  • a monitoring, re- evaluation and aggregation of the security scores may be performed using mechanisms described above. For instance, for a component exposing multiple interfaces as shown in Tables 4, 6 and 8, the data transmission security score may be re-evaluated whenever the connection security is reestablished or if certain expiry timers trigger and the security is not refreshed, etc.
  • the SPV of the entire slice can then be derived from these individual components' SPVs and published or maintained as a scalar or multi-value set as presented above.
  • a static (boot time) SPV evaluation is likely enough for the components that are part of the NVFI or Management domains (Table 3 - Table 6), because they are not subject to frequent changes, or at least not without some level of administrator manual intervention (e.g., MANO stack SAV update, add/change/configure physical router, server etc.).
  • these components may be continually monitored and the SPV score changed if vulnerabilities or attacks are detected, etc.
  • Fig. 17A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single-carrier FDMA
  • ZT UW DTS-s OFDM zero-tail unique-word DFT-Spread OFDM
  • UW-OFDM unique word OFDM
  • FBMC filter bank multicarrier
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • a netbook a personal computer
  • the communications systems 100 may also include a base station 114a and/or a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum.
  • a cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, i.e., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • beamforming may be used to transmit and/or receive signals in desired spatial directions.
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 116 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).
  • DL High-Speed Downlink
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed UL Packet Access
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A) and/or LTE- Advanced Pro (LTE-A Pro).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE- Advanced
  • LTE-A Pro LTE- Advanced Pro
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
  • a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies.
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles.
  • DC dual connectivity
  • the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., a eNB and a gNB).
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.11 i.e., Wireless Fidelity (WiFi)
  • IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for
  • the base station 114b in Fig. 17A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • WLAN wireless local area network
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell.
  • the base station 114b may have a direct connection to the Internet 110.
  • the base station 114b may not be required to access the Internet 110 via the CN 106/115.
  • the RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like.
  • QoS quality of service
  • the CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT.
  • the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.
  • the CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers.
  • the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.
  • the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links).
  • the WTRU 102c shown in Fig. 17A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • Fig. 17B is a system diagram illustrating an example WTRU 102. As shown in Fig.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • GPS global positioning system
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Fig. 17B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116.
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Intemet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like.
  • FM frequency modulated
  • the peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
  • a gyroscope an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.
  • the WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or
  • the full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118).
  • the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).
  • Fig. 17C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 104 may also be in communication with the CN 106.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in Fig. 17C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the CN 106 shown in Fig. 17C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • the MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S I interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer
  • the MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.
  • the SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface.
  • the SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • packet-switched networks such as the Internet 110
  • the CN 106 may facilitate communications with other networks.
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
  • the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRU is described in Fig. 17A-17D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.
  • the other network 112 may be a WLAN.
  • a WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP.
  • the AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS.
  • Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations.
  • DS Distribution System
  • Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA.
  • the traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic.
  • the peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS).
  • the DLS may use an 802. l ie DLS or an 802.1 lz tunneled DLS (TDLS).
  • a WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other.
  • the IBSS mode of communication may sometimes be referred to herein as an "ad-hoc" mode of communication.
  • the AP may transmit a beacon on a fixed channel, such as a primary channel.
  • the primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling.
  • the primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP.
  • Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems.
  • the STAs e.g., every STA, including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off.
  • One STA (e.g., only one station) may transmit at any given time in a given BSS.
  • High Throughput (HT) STAs may use a 40 MHz wide channel for
  • VHT STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels.
  • the 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels.
  • a 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration.
  • the data, after channel encoding may be passed through a segment parser that may divide the data into two streams.
  • Inverse Fast Fourier Transform (IFFT) processing, and time domain processing may be done on each stream separately.
  • IFFT Inverse Fast Fourier Transform
  • the streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA.
  • the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).
  • MAC Medium Access Control
  • Sub 1 GHz modes of operation are supported by 802.1 laf and 802.1 lah.
  • the channel operating bandwidths, and carriers, are reduced in 802.1 laf and 802.1 lah relative to those used in 802.11 ⁇ , and 802.1 lac.
  • 802.1 laf supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum
  • 802.1 lah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a
  • 802.1 lah may support Meter Type Control/Machine-Type
  • MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths.
  • the MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).
  • WLAN systems which may support multiple channels, and channel bandwidths, such as 802.1 In, 802.1 lac, 802.1 laf, and 802.1 lah, include a channel which may be designated as the primary channel.
  • the primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS.
  • the bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode.
  • the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes.
  • Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.
  • STAs e.g., MTC type devices
  • NAV Network Allocation Vector
  • the available frequency bands which may be used by 802.1 lah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.
  • Fig. 17D is a system diagram illustrating the RAN 113 and the CN 1 15 according to an embodiment.
  • the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
  • the RAN 1 13 may also be in communication with the CN 115.
  • the RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment.
  • the gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one
  • the gNBs 180a, 180b, 180c may implement MIMO technology.
  • gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c.
  • the gNB 180a may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.
  • the gNBs 180a, 180b, 180c may implement carrier aggregation technology.
  • the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum.
  • the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology.
  • WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum.
  • the WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time).
  • TTIs subframe or transmission time intervals
  • the gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c).
  • WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point.
  • WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band.
  • WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c.
  • WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously.
  • eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.
  • Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in Fig. 17D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • the CN 115 shown in Fig. 17D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 1 15, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.
  • SMF Session Management Function
  • the AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node.
  • the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like.
  • Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.
  • different network slices may be established for different use cases such as services relying on ultra- reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like.
  • URLLC ultra- reliable low latency
  • eMBB enhanced massive mobile broadband
  • MTC machine type communication
  • the AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • radio technologies such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.
  • the SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an Ni l interface.
  • the SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface.
  • the SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.
  • the SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.
  • a PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.
  • the UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate
  • the UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
  • the CN 115 may facilitate communications with other networks.
  • the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.
  • the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.
  • DN local Data Network
  • the emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein.
  • the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.
  • the emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.
  • the one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network.
  • the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components.
  • the one or more emulation devices may be test equipment. Direct RF coupling and/or wireless
  • RF circuitry e.g., which may include one or more antennas
  • RF circuitry may be used by the emulation devices to transmit and/or receive data.
  • each feature or element can be used alone or in any combination with the other features and elements.
  • the embodiments described herein are provided for exemplary purposes only.
  • the embodiments described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor.
  • Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media.
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto- optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Il est un fait qu'avec la révolution du modèle d'entreprise et de l'architecture de réseau 5G, la sécurité d'infrastructure de réseau (NIS) devient un aspect critique d'une tranche de réseau (NS). L'invention concerne un cadre et une approche systématiques qui peuvent être utilisés pour évaluer et mesurer le niveau de confiance (ou le risque impliqué par les divers modèles et services de déploiement devant être fournis), et faciliter la livraison sécurisée des services 5G anticipés via des tranches, des fonctions de réseau individuelles, ou une infrastructure de réseau classique. En outre, les processus de déduction et de mesurage du niveau de confiance tiennent compte des exigences de politique de différentes parties prenantes et des attributs de sécurité que la partie prenante juge importants pour l'évaluation du niveau de confiance. Il est un fait que ce dernier aspect peut revêtir une importance critique pour des réseaux 5G car une grande partie de l'infrastructure ne peut pas être partagée ni détenue par les opérateurs.
PCT/US2017/057661 2016-10-20 2017-10-20 Détermination et communication d'attributs de posture de sécurité WO2018075930A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662410561P 2016-10-20 2016-10-20
US62/410,561 2016-10-20

Publications (1)

Publication Number Publication Date
WO2018075930A1 true WO2018075930A1 (fr) 2018-04-26

Family

ID=60268473

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/057661 WO2018075930A1 (fr) 2016-10-20 2017-10-20 Détermination et communication d'attributs de posture de sécurité

Country Status (1)

Country Link
WO (1) WO2018075930A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110445788A (zh) * 2019-08-09 2019-11-12 西安电子科技大学 一种车载自组网环境下面向内容的信任评估系统及方法
CN110912722A (zh) * 2018-09-17 2020-03-24 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
WO2021034906A1 (fr) * 2019-08-19 2021-02-25 Q Networks, Llc Procédés, systèmes, kits et appareils de fourniture d'une télécommunication de cinquième génération sécurisée et dédiée, de bout en bout
WO2022023068A1 (fr) * 2020-07-26 2022-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Orchestration d'un service
US11316803B1 (en) * 2017-11-30 2022-04-26 Open Invention Network Llc VNFM resolution of split-brain virtual network function components
WO2022128126A1 (fr) * 2020-12-18 2022-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Niveau de confiance dans les tranches de réseau
CN114840856A (zh) * 2022-04-26 2022-08-02 浙江大学 一种状态感知的物联网可信执行环境模糊测试方法和系统
CN115277153A (zh) * 2022-07-22 2022-11-01 国网山东省电力公司电力科学研究院 一种智能电网5g网络风险评估系统及评估方法
WO2022268318A1 (fr) * 2021-06-24 2022-12-29 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareil de commande réseau
CN115767550A (zh) * 2022-12-02 2023-03-07 北京亚鸿世纪科技发展有限公司 一种5g专网的网络风险评估的方法和装置
WO2023078546A1 (fr) * 2021-11-03 2023-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Configuration d'attestation et de sécurité d'un service

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1324541A2 (fr) * 2001-12-26 2003-07-02 Kabushiki Kaisha Toshiba Système de communication, dispositif de communication sans fil et procédé de communication
US20050097357A1 (en) * 2003-10-29 2005-05-05 Smith Michael R. Method and apparatus for providing network security using security labeling
US20110231443A1 (en) * 1999-02-16 2011-09-22 Clifford Lee Hannel Query interface to policy server

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110231443A1 (en) * 1999-02-16 2011-09-22 Clifford Lee Hannel Query interface to policy server
EP1324541A2 (fr) * 2001-12-26 2003-07-02 Kabushiki Kaisha Toshiba Système de communication, dispositif de communication sans fil et procédé de communication
US20050097357A1 (en) * 2003-10-29 2005-05-05 Smith Michael R. Method and apparatus for providing network security using security labeling

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11606315B1 (en) 2017-11-30 2023-03-14 Google Llc VNFM handling of faults in virtual network function components
US11736416B1 (en) 2017-11-30 2023-08-22 Google Llc Coordinated switch of activity in virtual network function components
US11372670B1 (en) 2017-11-30 2022-06-28 Open Invention Network Llc Split-brain resolution in virtual network function components
US11379257B1 (en) 2017-11-30 2022-07-05 Open Invention Network Llc Split-brain resolution in virtual network function components
US11888762B1 (en) 2017-11-30 2024-01-30 Google Llc VNFM assisted fault handling in virtual network function components
US11316803B1 (en) * 2017-11-30 2022-04-26 Open Invention Network Llc VNFM resolution of split-brain virtual network function components
US11368565B1 (en) 2017-11-30 2022-06-21 Open Invention Network Llc VNFM assisted split-brain resolution in virtual network function components
CN110912722A (zh) * 2018-09-17 2020-03-24 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
CN110912722B (zh) * 2018-09-17 2022-08-09 中兴通讯股份有限公司 业务资源管理方法、装置、网络设备和可读存储介质
CN110445788B (zh) * 2019-08-09 2021-07-27 西安电子科技大学 一种车载自组网环境下面向内容的信任评估系统及方法
CN110445788A (zh) * 2019-08-09 2019-11-12 西安电子科技大学 一种车载自组网环境下面向内容的信任评估系统及方法
WO2021034906A1 (fr) * 2019-08-19 2021-02-25 Q Networks, Llc Procédés, systèmes, kits et appareils de fourniture d'une télécommunication de cinquième génération sécurisée et dédiée, de bout en bout
WO2022023068A1 (fr) * 2020-07-26 2022-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Orchestration d'un service
WO2022128126A1 (fr) * 2020-12-18 2022-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Niveau de confiance dans les tranches de réseau
WO2022268318A1 (fr) * 2021-06-24 2022-12-29 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareil de commande réseau
WO2023078546A1 (fr) * 2021-11-03 2023-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Configuration d'attestation et de sécurité d'un service
CN114840856A (zh) * 2022-04-26 2022-08-02 浙江大学 一种状态感知的物联网可信执行环境模糊测试方法和系统
CN115277153A (zh) * 2022-07-22 2022-11-01 国网山东省电力公司电力科学研究院 一种智能电网5g网络风险评估系统及评估方法
CN115277153B (zh) * 2022-07-22 2023-11-03 国网山东省电力公司电力科学研究院 一种智能电网5g网络风险评估系统及评估方法
CN115767550A (zh) * 2022-12-02 2023-03-07 北京亚鸿世纪科技发展有限公司 一种5g专网的网络风险评估的方法和装置

Similar Documents

Publication Publication Date Title
WO2018075930A1 (fr) Détermination et communication d'attributs de posture de sécurité
Ranaweera et al. Survey on multi-access edge computing security and privacy
Alam et al. A survey of network virtualization techniques for Internet of Things using SDN and NFV
Ahmad et al. Security for 5G and beyond
Kotulski et al. Towards constructive approach to end-to-end slice isolation in 5G networks
Sood et al. Software-defined wireless networking opportunities and challenges for Internet-of-Things: A review
US11711754B2 (en) Dynamic functional partitioning for security pass-through virtual network function (VNF)
US9479450B2 (en) Resolving communication collisions in a heterogeneous network
CN110958227B (zh) 用于执行网络功能虚拟化nfv安全服务代理nfv ssa的方法和计算平台
WO2017200978A1 (fr) Sélection et attribution de tranches à base de sécurité
US11102176B2 (en) Community WiFi access point (AP) virtual network function (VNF) with WiFi protected access 2 (WPA2) pass-through
CN114567875A (zh) 用于无线电设备网络空间安全和多个无线电接口测试的技术
Salva-Garcia et al. 5G NB‐IoT: Efficient Network Traffic Filtering for Multitenant IoT Cellular Networks
Ranaweera et al. Realizing multi-access edge computing feasibility: Security perspective
WO2018013925A1 (fr) Structure d'autorisation adaptative pour réseaux de communication
US9009779B2 (en) Methods related to network access redirection and control and devices and systems utilizing such methods
US20230006889A1 (en) Flow-specific network slicing
US11340933B2 (en) Method and apparatus for secrets injection into containers for 5G network elements
US11606416B2 (en) Network controlled machine learning in user equipment
US11716627B2 (en) Trusted 5G network slices
WO2022261244A1 (fr) Solutions conformes à la directive sur les équipements radio pour des exigences sur la cybersécurité, la confidentialité et la protection du réseau
EP4360348A1 (fr) Sécurité pour découpage en tranches d'un réseau 5g
WO2023069757A1 (fr) Ingénierie de trafic dans des topologies de matrices avec des services déterministes
Ahmad et al. Design principles for 5G security
US20230092245A1 (en) Resistance to side-channel attacks on 5g network slices

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17794842

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17794842

Country of ref document: EP

Kind code of ref document: A1