Method for generating slice subnet profile associated with network slice
The method for creating a slice subnet profile addresses the complexity of 5G networks by deriving and transmitting profiles that enhance network slicing, ensuring secure and efficient operation for diverse services and devices.
Patent Information
- Application Number
- PCT/KR2025/009858
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-08
- Filing Date
- 2025-07-08
- Publication Date
- 2026-01-15
AI Technical Summary
Current 5G wireless communication systems face challenges in managing the increased complexity and connectivity demands of emerging services and devices, necessitating enhanced network slicing capabilities to support diverse requirements and ensure security, trustworthiness, and performance.
A method for creating a slice subnet profile associated with a network slice, involving deriving and transmitting a slice subnet profile based on service requirements, including attributes for encryption, security monitoring, and trustworthiness, to enable secure and efficient network function creation.
Enhances network slicing by ensuring secure and efficient operation of network functions, meeting diverse service demands and improving network performance and security.
Smart Images

Figure KR2025009858_15012026_PF_FP_ABST
Abstract
Description
How to create a slice subnet profile associated with a network slice
[0001] The present disclosure relates to network slicing, and more particularly, to a method for creating a slice subnet profile associated with a network slice.
[0002] 5G wireless communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G wireless communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G wireless communication technology and an ultra-low latency time that is reduced to one-tenth.
[0003] In the early stages of 5G wireless communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.
[0004] Currently, discussions are underway to improve and enhance the initial 5G wireless communication technology in consideration of the services that 5G wireless communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.
[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.
[0006] Once these 5G wireless communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G wireless communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).
[0007] In addition, the development of these 5G wireless communication systems includes new waveforms to ensure coverage in the terahertz band of 6G wireless communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G wireless communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that goes beyond the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.
[0008] A method performed by a first network entity according to one embodiment of the present disclosure may include: receiving a service profile associated with requirements for a network slice; deriving (202) a slice subnet profile associated with requirements for a network slice subnet of a specific domain based on the service profile; and transmitting the slice subnet profile to a second network entity of the specific domain. The service profile may include at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm, a second attribute indicating whether a requirement for monitoring security performance of the network slice is enabled, or a third attribute indicating trustworthiness of one or more nodes within the network slice.
[0009] A method performed by a first network entity according to one embodiment of the present disclosure may include: receiving a slice subnet profile associated with requirements of a network slice subnet for a domain in which the first network entity is included; deriving, based on the slice subnet profile, requirements associated with the network slice, the requirements associated with the network slice subnet; and requesting a second network entity of the domain in which the first network entity is included to create a network function that satisfies the derived requirements. The slice subnet profile may include at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm, a second attribute indicating whether a requirement for monitoring security performance of the network slice is enabled, or a third attribute indicating trustworthiness of network entities associated with the network slice.
[0010] A network entity according to one embodiment of the present disclosure may include: at least one processor; and a memory coupled to the processor, the memory storing at least one instruction. By the at least one processor executing the at least one instruction stored in the memory, the network entity may: receive a service profile associated with requirements for a network slice, derive a slice subnet profile associated with requirements for a network slice subnet of a specific domain based on the service profile, and transmit the slice subnet profile to a second network entity of the specific domain. The service profile may include at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm, a second attribute indicating whether a requirement for monitoring the security performance of the network slice is activated, or a third attribute indicating trustworthiness of one or more nodes within the network slice.
[0011] FIG. 1 illustrates a network slice management and orchestration system according to one embodiment of the present disclosure.
[0012] FIG. 2 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0013] FIG. 3 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0014] FIG. 4 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0015] FIG. 5 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0016] FIG. 6 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0017] FIG. 7 illustrates a flowchart of a method (700) according to one embodiment of the present disclosure.
[0018] FIG. 8 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0019] FIG. 9 illustrates network slices according to one embodiment of the present disclosure.
[0020] FIG. 10 illustrates network entities according to one embodiment of the present disclosure.
[0021] FIGS. 11A and 11B illustrate network entities according to one embodiment of the present disclosure.
[0022] FIG. 12 illustrates a block diagram of a network infrastructure according to one embodiment of the present disclosure.
[0023] FIG. 13 illustrates a block diagram of a network entity according to one embodiment of the present disclosure.
[0024] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.
[0025] In describing the embodiments, descriptions of technical details that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to ensure that the gist of the present disclosure is conveyed more clearly without obscuring it by omitting unnecessary explanations.
[0026] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. In each drawing, identical or corresponding components are assigned the same or different reference numbers.
[0027] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification. In addition, when describing the present disclosure, if a specific description of a related function or configuration is determined to unnecessarily obscure the gist of the present disclosure, the detailed description thereof will be omitted. In addition, the terms described below are terms defined in consideration of the functions of the present disclosure, and these may vary depending on the intention or custom of the user or operator. Therefore, their definitions should be made based on the contents throughout the specification.
[0028] In the present disclosure, it will be appreciated that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed based on computer program instructions. These computer program instructions can be selectively installed in at least one processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by any one or any combination of at least one processor of the computer or other programmable data processing equipment create means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce an article of manufacture that includes instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).
[0029] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions mentioned in the blocks may occur out of order. For example, two blocks (or functions) depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on the corresponding function.
[0030] The term '~ unit' used in the embodiments of the present disclosure means a software or hardware component such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and the '~ unit' performs certain roles. However, terms including '~ unit' are not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Thus, as an example, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided within the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. In addition, the components and '~parts' may be implemented to play one or more central processing units (CPUs) within the device or secure multimedia card. Also, in an embodiment, the '~parts' may include one or more processors.
[0031] As described above, it should be noted that the blocks and combinations of flowcharts described in the present disclosure may be implemented by one or more computer programs containing instructions. One or more computer programs may be stored entirely in a single memory device, or one or more computer programs may be divided and stored in different portions across multiple memory devices.
[0032] Additionally, any / any function or operation described in the present disclosure may be processed by a single processor or a combination of processors. The single processor or the combination of processors may include circuitry that performs processing, such as an application processor (AP, e.g., a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near-field communication (NFC) chip, a connectivity chip, a sensor controller, a touch controller, a fingerprint sensor controller, a display driver integrated circuit (IC), an audio codec (CODEC) chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on a chip (SoC), an IC, or similar circuitry.
[0033] It should also be noted that the various embodiments in the claims and description of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.
[0034] Such software may be stored on a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores one or more computer programs (software modules), wherein the one or more computer programs include computer-executable instructions that, when executed alone or collectively by one or more processors of an electronic device, cause the electronic device to perform a method according to the present disclosure.
[0035] The software may be stored in a temporary or non-transitory storage device, for example, in the form of a read-only memory (ROM) (whether erasable or rewritable), a random access memory (RAM), a memory chip, a device, or an integrated circuit (IC). The software may also be stored in an optically or magnetically readable medium, for example, a compact disc (CD), a digital versatile disc (DVD), a magnetic disk, or a magnetic tape. It should be understood that the storage device and the storage medium are examples of non-transitory machine-readable storage media suitable for storing a program for implementing various embodiments of the present disclosure. Accordingly, various embodiments of the present disclosure may provide a program comprising code for implementing a device or method according to any one of the claims of the present specification, and a non-transitory machine-readable storage medium storing such a program.
[0036] In the present disclosure, determining the priority between A and B may be referred to in various ways, such as selecting a higher priority according to a predetermined priority rule and performing an action corresponding to it, or omitting or dropping an action for a lower priority.
[0037] Hereinafter, 'A or B' described in the present disclosure may be understood as 'A and / or B', which may be understood to include 'A', or 'B', or 'A and B'.
[0038] Additionally, 'at least one of A, B, and C' described in the present disclosure may be understood to include 'A', or 'B', or 'C', or 'any combination of A, B, and C'.
[0039] Additionally, 'at least one of A, B, or C' described in the present disclosure may be understood to include 'A', or 'B', or 'C', or 'any combination of A, B, and C'.
[0040] Additionally, 'A / B' described in the present disclosure may be understood as 'A and / or B', which may be understood to include 'A', or 'B', or 'A and B'.
[0041] Additionally, 'A, B' described in the present disclosure may be understood as 'A and / or B', which may be understood to include 'A', or 'B', or 'A and B'.
[0042] Additionally, 'A and B' described in the present disclosure may be understood as 'A and / or B', which may be understood to include 'A', or 'B', or 'A and B'.
[0043] In addition, it can be understood that the 'case where conditions A and B are satisfied' described in the present disclosure is not necessarily limited to the case where both conditions A and B are satisfied, but may include the case where each of conditions A or B is satisfied, the case where both conditions A and B are satisfied, or the case where one or more additional conditions are satisfied together.
[0044] Additionally, throughout this specification, ordinal terms such as "first," "second," "third," and the like (and modifiers thereof) are used solely to distinguish between various instances, occurrences, configurations, messages, stages, or aspects of elements, operations, or information, as described below. Unless the context clearly requires otherwise, the use of such ordinal terms does not require that the elements, operations, or information distinguished by them be structurally, numerically, or inherently different. For example, "a first signal" and "a second signal" may represent instances of the same signal transmitted at different times, may represent signals containing the same core information albeit with some modifications, or may represent signals having different content or characteristics depending on the specific context. Similarly, "a first value" and "a second value" may represent measurements or applications of the same magnitude in different circumstances, or may represent different magnitudes. Such interpretation should be determined by the specific technical context, functions and relationships described in the relevant portions of the specification and claims.
[0045] Furthermore, although terms such as "first" and "second" described in this disclosure are used to refer to various elements such as information, objects, actions, and sequences, they are not intended to limit such elements to a specific order. These terms may be understood to be used merely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element.
[0046] Additionally, it may be understood that the terms "first~" and "second~" described in this disclosure may refer to the same or different elements. For example, if the elements are information, the first information and the second information may both be information, and in some cases, they may be the same information or different information.
[0047] In addition, the expressions "if" and "in case that" described in the present disclosure or claims may be interpreted to mean "when or upon," "in response to," or "based on," or "according to," depending on the context, and these expressions may be used interchangeably. In addition, in addition to these expressions, other expressions having substantially the same meaning may be used interchangeably, within the scope that does not impair the technical features of the present disclosure.
[0048] Additionally, the term "not perform" as used in this disclosure or claims may be understood to mean omitting or skipping a step, depending on the context. Such terms may be replaced with other terms having the same or substantially similar meaning.
[0049] Additionally, "transmitting a message including A and B" as described herein may be interpreted to include both (i) cases where A and B are transmitted in a single message, as well as (ii) cases where A and B are transmitted individually via multiple messages (e.g., transmitting a first message including A and a second message including B). This interpretation may also apply when a message including two or more items, such as A, B, and C, is transmitted together or individually.
[0050] Additionally, 'sending a message containing A and sending a message containing B' can also be interpreted as sending a single message containing A and B.
[0051] In the specific embodiments of the present disclosure described below, terms or components included in the disclosure will be expressed in the singular or plural, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural may be composed of singular elements, or components expressed in the singular may be composed of plural elements.
[0052] The drawings or flowcharts described below illustrate exemplary methods that may be implemented according to the principles of the present disclosure, and various modifications may be made to the methods depicted in the flowcharts of the present disclosure. For example, although depicted as a series of steps, various steps in each drawing or flowchart may overlap, occur in parallel, occur in different orders, or occur multiple times. In other instances, any step may be omitted or replaced with another step.
[0053] The methods and devices proposed in the embodiments of the present disclosure are not limited to each embodiment, and may be utilized as a combination of one or more embodiments, all or part of the embodiments proposed in the disclosure. Accordingly, the embodiments of the present disclosure may be applied with some modifications within a scope that does not significantly deviate from the scope of the present disclosure, as determined by a person skilled in the art.
[0054] In this case, even if any wording is mentioned in different embodiments, if the concepts correspond, they may be used interchangeably, combined, or substituted. For example, for identical or corresponding concepts, even if one embodiment uses the expression "A" and another embodiment uses the expression "B," these may be understood interchangeably, substituted, or combined.
[0055] In the following description, terms used to identify connection nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, etc. are examples for convenience of explanation. Therefore, the present disclosure is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used. In addition, the terms may be replaced with terms defined in the 3rd generation partnership project (3GPP) Technical Specifications (TS), if appropriate.
[0056] Hereinafter, the base station is an entity that performs resource allocation of a terminal, and may be at least one of a gNode B, an eNode B, a Node B, a BS (base station), a radio access unit, a base station controller, or a node on a network. In addition, the base station of the present disclosure may include a structure that is split into a central unit (CU) and a distributed unit (DU). In this structure, the CU is responsible for the upper layers of the control and user planes, and the DU is responsible for radio resource processing of the lower layers. The embodiments of the present disclosure can be equally applied to a 5G base station structure in which functions are separated into the CU and DU.
[0057] The terminal may include a UE (user equipment), MS (mobile station), cellular phone, smartphone, computer, or multimedia system capable of performing communication functions.
[0058] In the present disclosure, downlink (DL) refers to a wireless transmission path of a signal transmitted from a base station to a terminal, and uplink (UL) refers to a wireless transmission path of a signal transmitted from a terminal to a base station.
[0059] In addition, although the fifth generation mobile communication system (5G, new radio, NR) and the sixth generation mobile communication system (6G) may be described below as examples, the embodiments of the present disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, this may include new evolved mobile communication systems developed after 5G and 6G. In addition, the present disclosure may be applied to other communication systems (e.g., Wi-Fi systems) with some modifications within a range that does not significantly deviate from the scope of the present disclosure, as determined by a person having skilled technical knowledge.
[0060] In the following description, the terms "physical channel" and "signal" may be used interchangeably with data or control signals. For example, while PDSCH (physical downlink shared channel) refers to a physical channel through which data is transmitted, PDSCH may also be used to refer to data. That is, in the present disclosure, the expression "transmitting a physical channel" may be interpreted equivalently to the expression "transmitting data or a signal through a physical channel."
[0061] In the following description of the present disclosure, upper layer signaling may be signaling corresponding to at least one or a combination of one or more of MIB (master information block), SIB (system information block), SIB M (M=1, 2, …), RRC (radio resource control), MAC (medium access control) CE (control element), NAS (non-access stratum) signaling, or application layer messages. The RRC signaling may also be referred to as L3 signaling (layer 3 signaling).
[0062] In addition, L1 signaling may be signaling corresponding to at least one or a combination of one or more signaling methods using a physical layer channel or signaling of PDCCH (physical downlink control channel), DCI (downlink control information), UE-specific DCI, group common DCI, common DCI, scheduling DCI (e.g., DCI used for the purpose of scheduling downlink or uplink data), non-scheduling DCI (e.g., DCI not for the purpose of scheduling downlink or uplink data), physical uplink control channel (PUCCH), or uplink control information (UCI). The L1 signaling may also be referred to as physical layer signaling.
[0063] Hereinafter, the expression that information can be configured from a base station in the present disclosure or claims may mean that a terminal receives the information from the base station through physical layer signaling or upper layer signaling, depending on the context, and such expression may be replaced with other terms having the same or substantially similar meaning.
[0064] The terms used in this disclosure are selected from widely used, common terms, taking into account the functions of the disclosure. However, these terms may vary depending on the intentions of those skilled in the art, precedents, the emergence of new technologies, etc. Furthermore, in certain cases, terms may be arbitrarily selected by the applicant, in which case their meanings will be described in detail in the relevant description. Therefore, the terms used in this disclosure should not be defined simply as names, but rather based on the meanings of the terms and the overall content of the disclosure.
[0065] Singular expressions may include plural expressions unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art described herein. Furthermore, terms containing ordinal numbers, such as "first" or "second," used herein may be used to describe various components, but such components should not be limited by such terms. Such terms are used solely to distinguish one component from another.
[0066] When a part of the specification is said to "include" a component, this does not exclude other components, but rather implies the inclusion of other components, unless otherwise specifically stated. Furthermore, terms such as "unit" and "module" used in the specification mean a unit that processes at least one function or operation, which may be implemented in hardware, software, or a combination of hardware and software.
[0067] Below, with reference to the attached drawings, embodiments of the present disclosure are described in detail to facilitate easy implementation by those skilled in the art. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. Furthermore, for the sake of clarity in the drawings, portions irrelevant to the description have been omitted.
[0068] The 5G described below may also encompass existing LTE, LTE-A, and other similar services. Furthermore, the present disclosure may be applied to other communication systems with some modifications, as determined by those skilled in the art, without significantly departing from the scope of the present disclosure.
[0069] The operating principle of the present disclosure is described in detail with reference to the attached drawings below.
[0070] FIG. 1 illustrates a network slice management and orchestration system (100) according to one embodiment of the present disclosure.
[0071] A network slice is a logical network that provides specific network capabilities and network characteristics to support various service characteristics for Network Slice Customers (NSCs). Network slicing, a technology defined in wireless communication systems, is a technology for providing hardware infrastructure resources according to the requirements of various services through virtualization technology. For example, a network slice can be customized according to specific requirements agreed upon between an NSC and a Network Slice Provider (NSP). A network slice can span multiple network domains used by the NSP (e.g., a (Radio) Access Network ((R)AN), a Core Network (CN), and a Transport Network (TN). A network slice can include dedicated and / or shared resources, such as resources in terms of functionality, processing power, storage, and bandwidth. Dedicated resources can be isolated from other network slices.
[0072] Network slicing can create new services or utilize existing infrastructure. Network Slice-as-a-Service (NSaaS) can create new services by virtualizing resources from existing infrastructure. Network slicing can be applied to various industries, such as 5G enterprise services, private 5G, Multi-Access Edge Computing (MEC), smart factories, 5G automobiles, Mission-Critical Push-to-Talk (MCPTX), healthcare, energy transmission control, government surveillance, emergency services, broadcasting and streaming, manufacturing, supply chain, gaming, railways, and automobiles. Network slicing can support Service Level Agreement (SLA)-based services, monitoring and guaranteeing SLA conditions.
[0073] In 5G NR, the Global System for Mobile Communications Association (GSMA) and 3GPP (3 rd The 3GPP (3GPP Generation Partnership Project) defines three network slices as standards for enhanced Mobile Broadband (MBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). Additionally, other methods for creating and providing network slice services according to operator requirements are standardized. According to network slicing defined by 3GPP, services for eMBB, URLLC, mMTC, and various verticals can be provided based on SLA requirements.
[0074] Network slicing can also be applied to application classification, security policies, big data analytics, and artificial intelligence (AI). Network slicing can reduce costs by utilizing shared infrastructure. Full, partial, logical, and / or physical isolation between network slices may be required to ensure network slicing security.
[0075] The system (100) may include a Communication Service Customer (CSC) (110), a Communication Service Provider (CSP) (120), and a Network Operator (NOP) (130). The CSC (110) is an entity that uses communication services. For example, the CSC (110) may include an end user, a tenant, or a vertical. The CSP (120) provides communication services. The CSP (120) designs, builds, and operates its communication services. The communication services provided by the CSP (120) may be built with or without a network slice. The NOP (130) may provide network services. The NOP (130) designs, builds, and operates its network to provide the services. Depending on the actual scenarios, the CSC (110), CSP (120), and NOP (130) may perform one or more roles. For example, a CSC (110) or CSP (120) that uses a network slice as a service may be understood as an NSC. For example, a CSP (120) or NOP (130) that provides a network slice as a service may be understood as an NSP. The commitment between the NSP and the NSC regarding the network provisioned as a service may be understood as an SLA. As part of the SLA, the NSC may declare service requirements to the NSP, and such requirements may constitute a Service Level Specification (SLS).
[0076] In one embodiment, a network entity performing a Communications Service Management Function (CSMF) within the system (100) may perform the role of a CSC (110). In one embodiment, a network entity performing a Network Slice Management Function (NSMF) within the system (100) may perform the role of a CSP (120). In one embodiment, a network entity performing a Network Slice Subnet Management Function (NSSMF) of a CN slice within the system (100), an entity performing an NSSMF of a RAN, and an entity performing an NSSMF of a TN may perform the role of a NOP (130).
[0077] To model network slices, the NetworkSlice Information Object Class (IOC) can be used. A Network Slice Instance (NSI) is a Managed Object Instance (MOI) of the NetworkSlice IOC. For example, a Network Slice NSI can be a representation of a set of Network Function (NF) instances that form a deployed network slice and the resources (compute, storage, and networking resources) required. The NSI represents the service perspective of a network slice that exposes a root Network Slice Subnet Instance (NSSI).
[0078] A network slice subnet has a set of associated requirements (e.g., requirements derived from service level requirements) applicable to the network slice subnet components, which may be referred to as a Slice Profile (or Slice Subnet Profile). A Slice Profile may be common across networks (e.g., applicable to all network slice subnet components, regardless of their type) or specific (e.g., applicable only to RAN NFs, or only to CN NF network slice components). A network slice subnet is a representation of a set of network functions (NFs) and associated resources (e.g., compute, storage, and network resources) that support a network slice. To model a network slice subnet, a NetworkSliceSubnet IOC may be used, which may include CN NFs and / or RAN NFs and / or NFs of other network slice subnets. NSI can be reflected through NetworkSliceSubnet IOCs and allocated resources. NSSI is the MOI of the NetworkSliceSubnet IOC.
[0079] Depending on industry and operator requirements, different service profiles can be used to represent SLS associated with network slices. Examples of service profiles include:
[0080] - Service profiles are used to capture the set of requirements for new network slices such as eMMB, massive Internet of Things (MIoT), and URLLC.
[0081] - Service profiles are used to capture a set of specific industry requirements for creating network slices such as vehicle-to-everything (V2X), smart grid, remote healthcare, etc.
[0082] According to the network slicing technology defined by the GSMA, a wireless communication system (e.g., system (100)) can obtain requirements defined by a Generic Network Slice Template (GST) (140) or a Network Slice Type (NEST) (15) and create (or modify) a network slice based on the obtained requirements. The GST (14) may be attributes that can characterize the type of a network slice. The GST (14) is a set of attributes that can characterize the type of a network slice and / or a service. For example, the GST (14) defines attributes for providing specific network slices required by various verticals such as eMBB, URLLC, or mMTC. The GST (14) is generic and is not tied to a specific network deployment.
[0083] A NEST (15) may be a GST (14) populated with values. For example, a NEST (15) is a template populated with appropriate values for attributes defined by a GST (14) to provide a specific network slice service. The values may be specified to express a set of given requirements (13) to support use cases (12) of an NSC (11). The GST (14) and / or the NEST (15) are used by an NSP to prepare (16) an NSI that satisfies a specific SLA for the NSC. A User Equipment (UE) may use a network slice when the associated Single Network Slice Selection Assistance Information (S-NSSAI) is included in the subscription information for the UE, along with any applicable information that maps to attributes and parameter values associated with the NEST (15). Attributes associated with the NEST (15) may be differentiated by service category. For example, when a property of NEST (15) includes a service category parameter and subscription information for a UE includes a parameter value associated with that service category, the UE can be targeted for differentiated services associated with that service category within the network slice.
[0084] The system (100) can provide network slices according to the SLA received in the form of GST (14) or NEST (14). For example, the CSC (110) can convert (or translate) the GST (14) or NEST (14) into a service profile (111). The CSC (110) can transmit the service profile (111) to the CSP (120). The CSP (120) can convert the received service profile (111) into a top slice subnet profile (121). Based on the top slice subnet profile (121), the CSP (120) can generate an individual slice subnet profile (122) for each domain (or domain network). For example, a CN slice subnet profile for a CN domain, a RAN slice subnet profile for a RAN domain, and / or a TN slice subnet profile for a TN domain can be converted (or translated) by the CSP (120) from a top slice subnet profile (121). Each slice subnet profile can represent a corresponding network slice subnet. The slice subnet profiles (122) can be transferred to the NOP (130). According to the slice subnet profile for each domain, the NOP (130) can create a network slice by setting properties defined in the corresponding slice subnet profile to each domain network component. For example, from the slice subnet profiles (122), the NOP (130) can convert (or translate) configuration parameters (131) of the corresponding domain. Based on the configuration parameters (131), networks (132), for example, a 5G Core Network (5GC), a New Generation-RAN (NG-RAN), and TNs can be configured, respectively.
[0085] Security technologies for network slicing include Network Slice Specific Authentication and Authorization (NSSAA) for additional authentication of network slice services provided by third parties in addition to URLLC, eMBB, and mMTC network slices defined by 3GPP, and integration with devices to provide security functions such as firewalls on the N6 interface connecting the network slice and the data network (DN). In addition, Network Slice Admission Control (NSAC) function can be provided to prevent attacks by providing access control to specific network slices. From an SLA perspective, GSMA defines properties that can set availability and isolation levels to provide network slice security. According to 3GPP, parameters for creating 5G network slices are defined in the form of a Network Resource Model (NRM).
[0086] Referring to FIG. 1, the GST (14) may include a list of multiple attributes. For example, the GST (14) may include various attributes for forming a network slice, such as the attribute 'coverageArea' that specifies the coverage area of the network slice, e.g., the geographic area accessible by the communication service, the attribute 'maxNumberofUEs' that specifies the maximum number of UEs that can access a network slice or network slice subnet instance simultaneously, the attribute 'uLThptPerUE' that defines the data rate supported by the network slice per UE, and the attribute 'dLThptPerSliceSubnet' that defines the data rate required for the network slice subnet of the downlink that must be ubiquitously available throughout the slice's coverage area.
[0087] To enhance the security of network slices, isolation between slices, generation of slice-specific security keys, and quantum-safe communication may be considered. For example, network slices for critical sectors (e.g., energy, emergency services, critical manufacturing, etc.) may need to be separated from general commercial network slices. Instead of using the same key to protect user plane data across all slices of a user equipment (UE), generation of slice-specific keys and use of different security algorithms for each slice may be considered to ensure integrity and confidentiality across different slices of the UE. With the advancement of quantum computing, quantum-safe communication across network slices may become necessary.
[0088] In one embodiment, to provide a security-enhanced Network Slice, attributes included in a service profile (e.g., service profile (111)) and a slice profile (e.g., top slice subnet profile (121) or slice subnet profiles (122) of each domain) for the NetworkSlice IOC and NetworkSliceSubnet IOC may be defined. For example, GST (14) may additionally include at least one of the attribute 'quantumProtection' for setting an encryption algorithm for quantum security, GST (14) for setting a differentiated security method for each network slice, 'securityNativeSlice' for setting a security method for each network slice, GST (14) for applying a security policy to the N3 interface between the RAN and the CN's User Plane Function (UPF), GST (14) for evaluating the performance of a network slice with enhanced security, or 'trustLevel' for indicating a trustworthy node within the network slice. These attribute(s) included in GST (14) may be reflected in the service profile (111), the top slice subnet profile (121), and the slice subnet profiles (122). These attributes and their respective sub-attributes that may be included in the service profile (111), top slice subnet profile (121), RAN slice subnet profile, and CN slice subnet profile, and the mapping relationship between the profiles are presented in Table 1.
[0089]
[0090] In one embodiment of the present disclosure, service profile attributes, top slice subnet profile attributes, RAN slice subnet profile attributes, and CN slice subnet profile attributes may be mapped as shown in Table 1. For example, attribute 'quantumProtection' of GST (14) may be mapped to attribute 'qauntumProtection' of service profile (111). Attribute 'qauntumProtection' of service profile (111) may be mapped to attribute 'qauntumProtection' of top slice subnet profile (121). Attribute 'qauntumProtection' of top slice subnet profile (121) may be mapped to attribute 'qauntumProtection' of RAN slice subnet profile and attribute 'qauntumProtection' of CN slice subnet profile. Based on the mapping relationship presented in Table 1, a top slice subnet profile (121) can be converted from a service profile (111), and a RAN slice subnet profile and a CN slice subnet profile can be converted from the top slice subnet (121).
[0091] Table 2 presents characteristics of the properties 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', and 'trustLevel', according to one embodiment of the present disclosure.
[0092]
[0093] In Table 2, 'S' indicates whether an attribute exists or not. 'O' indicates that the corresponding attribute is optional. For example, an attribute indicated by 'O' means that its value may not exist. 'T' means true, and 'F' means false. 'IsReadable' indicates whether the attribute is readable by the manager. 'IsWriteable' indicates whether the attribute is writable by the manager. 'IsInvariant' indicates whether the attribute is immutable. If 'IsWriteable' of a attribute indicates 'T', the manager can set its value when creating an object. After object creation, the manager can modify the initial value if 'isInvariant' of the attribute is 'T'. If 'isInvariant' of the attribute is 'F', the manager cannot modify the initial value. 'isNotifyable' identifies whether a notification should be sent when the attribute value changes. For example, according to Table 2, the properties 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', and 'trustLevel' are all optional, readable, writeable, non-invariant (or variant), and notifyable.
[0094] Table 3 presents sub-properties of the property 'qauntumProtection', according to one embodiment of the present disclosure.
[0095]
[0096] Referring to Table 3, the attribute 'quantumProtection' can have at least one of the attributes 'servAttrCom', 'pqcAlgList', or 'qkdAlgList' as a sub-attribute. The attribute 'servAttrCom' can indicate a characteristic of the corresponding attribute (i.e., the attribute 'quantumProtection'). The sub-attribute 'servAttrCom' of the attribute 'quantumProtection' can be indicated as 'Character attributes / Function related / API' (or can include these attributes as sub-attributes), which can indicate that the attribute 'quantumProtection' is an attribute that indicates a characteristic (e.g., an attribute that characterizes a slice) and provides a specific function in the form of an Application Programming Interface (API) (e.g., specifying a function provided by a slice). The attribute 'pqcAlgList' can indicate a Post Quantum Cryptography (PQC) algorithm. The attribute 'qkdAlgList' can indicate a Quantum Key Distribution (QKD) algorithm. In Table 3, 'CM' indicates that the corresponding attribute is conditionally mandatory, and 'M' indicates that the corresponding attribute is mandatory. For example, in Table 3, the sub-attribute 'servAttrCom' of the attribute 'quantumProtection' is conditionally mandatory, readable, non-writable, invariant, and notifiable. In one embodiment, the sub-attribute 'servAttrCom' of the attribute 'quantumProtection' is mandatory only if requirements are defined on 'quantumProtection', otherwise it is optional.The subproperties 'pqcAlgList' and 'qkdAlgList' of the property 'quantumProtection' are required, readable, writable, mutable, and notifiable.
[0097] Table 4 presents sub-properties of the sub-property 'pqcAlgList' of the property 'quantumProtection', according to one embodiment of the present disclosure.
[0098]
[0099] Referring to Table 4, the sub-property 'pqcAlgList' of the property 'quantumProtection' can include at least one of the property 'pqcAlgId' and the property 'cipherSuite' as sub-properties. The property 'pqcAlgId' can indicate the ID (Identification) of the sub-property 'pqcAlgList'. The property 'cipherSuite' can include at least one of the properties indicating the type of the PQC algorithm, the type of the authentication algorithm, the type of the encryption algorithm, the type of the integrity check algorithm, and the encryption key (or its lifetime). For example, the property 'cipherSuite' can be input in the form of cipherSuite such as 'pqcAlgType' / authType / encType / intType / KeyLifeTime'. Referring to Table 4, the property 'pqcAlgId' is required, readable, non-writable, immutable, and notifiable. The attribute 'cipherSuite' is required, readable, writable, mutable, and notifiable.
[0100] Table 5 presents sub-properties of the sub-property 'qkdAlgList' of the property 'quantumProtection', according to one embodiment of the present disclosure.
[0101]
[0102] Referring to Table 5, the sub-property 'qkdAlgList' of the property 'quantumProtection' can include at least one of the properties 'qkdAlg', 'cipherSuite', or 'qkdSupport' as a sub-property. The property 'qkdAlgId' can indicate the ID of the sub-property 'qkdAlgList'. The sub-property 'cipherSuite' of the property 'qkdAlgList' can include at least one of the properties indicating the type of QKD algorithm, or the encryption key (or its lifetime). For example, the sub-property 'cipherSuite' of the property 'qkdAlgList' can be input in the form of cipherSuite, such as 'qkdAlgType / KeyLifeTime'. The sub-property 'qkdSupport' of the property 'qkdAlgList' can indicate whether the QKD function is supported. Referring to Table 5, the 'qkdAlgId' property is mandatory, readable, non-writable, immutable, and notifiable. The 'cipherSuite' property is mandatory, readable, writable, mutable, and notifiable. The 'qkdSupport' property is mandatory, readable, non-writable, mutable, and notifiable.
[0103] In one embodiment, the attribute 'quantumProtection' may further include a sub-attribute indicating one of various quantum security encryption algorithms, in addition to the PCQ algorithm and the QKD algorithm. This sub-attribute may be structured in a similar manner to the aforementioned attributes 'pqcAlgList' and 'qkdAlgList'. For example, this sub-attribute may include attributes indicating the type of the corresponding encryption algorithm and the encryption key.
[0104] Table 6 presents sub-properties of the property 'securityNativeSlice', according to one embodiment of the present disclosure.
[0105]
[0106] Referring to Table 6, the attribute 'securityNativeSlice' can have at least one of the attributes 'servAttrCom' and 'sliceSecList' as sub-attributes. The attribute 'servAttrCom' can indicate the characteristics of the corresponding attribute (i.e., the attribute 'securityNativeSlice'). The sub-attribute 'servAttrCom' of the attribute 'securityNativeSlice' can be indicated as 'Character attributes / Function related / API', which can indicate that the attribute 'securityNativeSlice' is an attribute that indicates characteristics and provides a specific function in the form of an API. The attribute 'sliceSecList' can indicate a slice-specific encryption algorithm (e.g., an encryption algorithm to be applied to, designated for, or assigned to a specific network slice). In Table 6, the sub-attribute 'servAttrCom' of the attribute 'securityNativeSlice' is conditionally required, readable, non-writable, immutable, and notifiable. In one embodiment, the subproperty 'servAttrCom' of the property 'securityNativeSlice' is required only if requirements are defined on 'securityNativeSlice', and is optional otherwise. The subproperty 'sliceSecList' of the property 'securityNativeSlice' is required, readable, writable, mutable, and notifiable.
[0107] Table 7 presents sub-properties of the sub-property 'sliceSecList' of the property 'securityNativeSlice', according to one embodiment of the present disclosure.
[0108]
[0109] Referring to Table 7, the sub-attribute 'sliceSecList' of the attribute 'securityNativeSlice' can include at least one of the attributes 'sliceSecId', 'cipherSuite', 'NEA', or 'NIA' as a sub-attribute. The attribute 'sliceSecId' can indicate the ID of the attribute 'sliceSecList'. The sub-attribute 'cipherSuite' of the attribute 'sliceSecList' can include at least one of the attributes indicating the type of encryption algorithm to be applied to the network slice, the type of authentication algorithm, the type of encryption algorithm, the type of integrity check algorithm, or the encryption key (or its lifetime). For example, the sub-attribute 'cipherSuite' of the attribute 'sliceSecList' can be entered in the form of cipherSuite, such as 'secAlgType / authType / encType / intType / KeyLifeTime'. The attribute 'NEA' is an attribute to support the use of the New Radio Encryption Algorithm (NEA) defined in 3GPP. The attribute 'NIA' is an attribute to support the use of the New Radio Integrity Algorithm (NIA) defined in 3GPP. For example, depending on the values of the attribute 'NEA' and the attribute 'NIA', the NEA algorithm and / or NIA algorithm defined in 3GPP, such as NEA0, 128-NEA1 based on SNOW3G, 128-NEA2 based on AES, and 128-NEA3 based on ZUC, can be applied to the network slice. In one embodiment, if indicated by the attributes 'NEA' and 'NIA', the SNOW3G and AES-based algorithms are necessarily implemented and optionally used, and the ZUC-based algorithm is optionally implemented and optionally used.Referring to Table 7, the attribute 'sliceSecId' is mandatory, readable, non-writable, immutable, and notifiable. The attributes 'cipherSuite', 'NEA', and 'NIA' are mandatory, readable, writable, mutable, and notifiable.
[0110] Table 8 presents sub-properties of the property 'n3Protection', according to one embodiment of the present disclosure.
[0111]
[0112] Referring to Table 8, the attribute 'n3Protection' can have at least one of the attributes 'servAttrCom' or 'n3SecList' as a sub-attribute. The attribute 'servAttrCom' can indicate the characteristics of the corresponding attribute (i.e., the attribute 'n3Protection'). The sub-attribute 'servAttrCom' of the attribute 'n3Protection' can be indicated as 'Character attributes / Function related / API', which can indicate that the attribute 'n3Protection' is an attribute that indicates characteristics and an attribute that provides a specific function in the form of an API. The attribute 'n3SecList' can be an attribute for supporting the security of the N3 interface. In Table 8, the sub-attribute 'servAttrCom' of the attribute 'n3Protection' is conditionally required, readable, non-writable, immutable, and notifiable. In one embodiment, the sub-property 'servAttrCom' of the property 'n3Protection' is required only if requirements are defined on 'n3Protection', otherwise it is optional. The sub-property 'n3SecList' of the property 'n3Protection' is required, readable, writable, mutable, and notifiable.
[0113] Table 9 presents sub-properties of the sub-property 'n3SecList' of the property 'n3Protection', according to one embodiment of the present disclosure.
[0114]
[0115] Referring to Table 9, the sub-property 'n3SecList' of the property 'n3Protection' can include at least one of the properties 'n3SecId', 'n3SecType', 'n3AuthType', or 'n3ReplayProtection' as a sub-property. The property 'n3SecId' can indicate the ID of the property 'n3SecList'. The property 'n3SecType' can indicate the type of encryption algorithm for the N3 interface. The property 'n3AuthType' can indicate the type of authentication algorithm for the N3 interface. The property 'n3ReplayProtection' can indicate whether the network slice supports replay protection for the N3 interface. Referring to Table 9, the property 'n3SecId' is required, readable, non-writable, immutable, and notifiable. The properties 'n3SecType', 'n3AuthType', and 'n3ReplayProtection' are required, readable, writable, mutable, and notifiable. In some embodiments, the properties 'n3SecType', 'n3AuthType', and 'n3ReplayProtection' may be based on “9.3 Security requirements and procedures on N3” of 3GPP TS 33.501 V18.5.0.
[0116] Table 10 presents sub-properties of the property 'securityPerformance', according to one embodiment of the present disclosure.
[0117]
[0118] Referring to Table 10, the attribute 'securityPerformance' can have at least one of the attributes 'servAttrCom' or 'secPerfList' as a sub-attribute. The attribute 'servAttrCom' can indicate the characteristics of the corresponding attribute (i.e., the attribute 'securityPerformance'). The sub-attribute 'servAttrCom' of the attribute 'securityPerformance' can be indicated as 'Character attributes / Function related / KPI' (or can include these attributes as sub-attributes), which can indicate that the attribute 'securityPerformance' is an attribute that indicates characteristics and provides specific performance in the form of a KPI (Key Performance Indicator). The attribute 'secPerfList' can be an attribute for monitoring the security performance of a network slice. In Table 10, the sub-attribute 'servAttrCom' of the attribute 'n3Protection' is conditionally required, readable, non-writable, immutable, and notifiable. In one embodiment, the sub-property 'servAttrCom' of the property 'securityPerformance' is required only if requirements are defined on 'securityPerformance', and is optional otherwise. The sub-property 'secPerfList' of the property 'securityPerformance' is required, readable, writable, mutable, and notifiable.
[0119] Table 11 presents sub-properties of the sub-property 'secPerfList' of the property 'securityPerformance', according to one embodiment of the present disclosure.
[0120]
[0121] Referring to Table 11, the sub-property 'secPerfList' of the property 'securityPerformance' can include at least one of the properties 'secPerfId', 'secPerfType', 'privacySupport', or 'resiliencySupport' as a sub-property. The property 'secPerfId' can indicate the ID of the property 'secPerfList'. The property 'secPerfType' can indicate the type of metric for evaluating performance according to the activation of the security function. For example, the property 'secPerfType' can indicate overhead measurement as a metric for evaluating security performance. The property 'privacySupport' can indicate whether a function for protecting privacy for a network slice is supported. For example, the property 'privacySupport' can indicate that a function for protecting privacy of a network slice, such as a function for preventing data breaches, is supported. The 'resiliencySupport' attribute can indicate whether a function for evaluating resilience against attacks on a network slice or a measurement for evaluating resilience is supported. For example, the 'resiliencySupport' attribute can indicate whether a measurement for evaluating resilience, such as measuring the time it takes to recover from an attack, is supported or whether a function for resilience is provided. Referring to Table 11, the 'secPerfId' attribute is required, readable, non-writable, immutable, and notifiable. The 'secPerfType' attribute is required, readable, writable, mutable, and notifiable. The 'privacySupport' and 'resiliencySupport' attributes are optional, readable, non-writable, mutable, and notifiable.
[0122] Table 12 presents sub-properties of the property 'trustLevel', according to one embodiment of the present disclosure.
[0123]
[0124] Referring to Table 12, the attribute 'trustLevel' can have at least one of the attributes 'servAttrCom' or 'trustList' as a sub-attribute. The attribute 'servAttrCom' can indicate the characteristics of the corresponding attribute (i.e., the attribute 'trustLevel'). The sub-attribute 'servAttrCom' of the attribute 'trustLevel' can be indicated as 'Character attributes / Function related / API', which can indicate that the attribute 'trustLevel' is an attribute that indicates characteristics and an attribute that provides a specific function in the form of an API. The attribute 'trustList' is an attribute for selecting and providing trusted nodes when configuring a network slice. For example, the attribute 'trustList' can indicate trusted nodes among the nodes of each domain of the network slice. In Table 12, the sub-attribute 'servAttrCom' of the attribute 'trustLevel' is conditionally required, readable, non-writable, immutable, and notifiable. In one embodiment, the sub-property 'servAttrCom' of the property 'trustLevel' is required only if requirements are defined on 'trustLevel', and is optional otherwise. The sub-property 'trustList' of the property 'trustLevel' is required, readable, writable, mutable, and notifiable.
[0125] Table 13 presents sub-properties of the sub-property 'trustList' of the property 'trustList', according to one embodiment of the present disclosure.
[0126]
[0127] Referring to Table 13, the sub-attribute 'trustList' of the attribute 'trustLevel' can include at least one of the attributes 'trustId', 'xhaulTrustTN', 'RANTrustNF', or 'CNTrustNF' as a sub-attribute. The attribute 'trustId' can indicate an ID of the attribute 'trustList'. The attribute 'xhaulTrustTN' can indicate one or more trusted nodes within the haul interfaces (or sections) of the RAN domain of the network slice, for example, the fronthaul, midhaul, and backhaul interfaces. Based on the attribute 'xhaulTrustTN', specific TN devices can be selected for trust in the fronthaul, midhaul, and backhaul interfaces of the RAN domain. The attribute 'RANTrustNF' can indicate one or more trusted NFs in the RAN domain of the network slice. The attribute 'CNTrustNF' can point to one or more trusted NFs in the CN domain of a network slice. Based on the attributes 'RANTrustNF' and 'CNTrustNF', trusted NFs can be selected when configuring a network slice. Referring to Table 13, the attribute 'trustId' is mandatory, readable, non-writable, immutable, and notifiable. The attribute 'xhaulTrustTN' is mandatory, readable, writable, mutable, and notifiable. The attributes 'RANTrustNF' and 'CNTrustNF' are optional, readable, writable, mutable, and notifiable.
[0128] In Tables 2 to 13 described above, some attributes are indicated as mandatory ('M'). However, embodiments of the present disclosure are not limited thereto, and those skilled in the art will understand that, depending on actual service requirements, a GST, NEST, service profile, or slice (subnet) profile may include at least some (i.e., any combination of these attributes) of the attributes described in Tables 2 to 13 (or the attributes described in Table 1).
[0129] Tables 14 through 19 present the definitions, allowed values, and properties of the attributes presented in Tables 2 through 13.
[0130]
[0131]
[0132]
[0133]
[0134]
[0135]
[0136] In the 'Properties' column of Tables 14 to 19, 'Type' can indicate the data type of the property. 'ENUM' can mean that the type of the property is an enumeration. For example, a property of type 'ENUM' can contain a set of named literals representing the values of the enumeration. 'integer' can indicate that the data type of the property is an integer. 'string' can indicate that the data type of the property is a string. 'Multiplicity' defines the number of values that the property can have simultaneously. If 'Multiplicity' is '1', the property has one property value. 'isOrdered' specifies whether the values of this property instance are ordered sequentially for a multiplicity of multi-values. 'isUnique' specifies whether the values of this property instance are unique (i.e., no duplicate property values) given a multiplicity of values. 'defaultValue' identifies the value at a given point in time used when an object is created. If there is no default value defined, the property may be omitted from the property description or specified as 'defaultValue: None'. 'allowedValues' specifies restrictions on the data type defined by the type. If no restrictions exist, the property may not exist. 'isNullable' identifies that the property may not carry information. 'N / A' may mean Not Applicable. 'None' may mean the property does not exist.
[0137] FIG. 2 illustrates a flowchart of a method (200) according to one embodiment of the present disclosure.
[0138] Referring to FIG. 2, a method (200) for creating a network slice, performed by a network entity, may be presented. In one embodiment, the method (200) of FIG. 2 may be performed by a CSP entity, an NSP entity, or an NSMF entity that supplies a network slice.
[0139] In step (201), a network entity may receive a service profile associated with requirements associated with a network slice. In one embodiment, the service profile may include at least one of the attributes 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', or 'trustLevel' described in Table 1. For example, the service profile may include at least one of an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security, an attribute indicating whether the network slice is protected by a specific cryptographic algorithm, an attribute indicating whether the N3 interface between a RAN domain and a UPF entity is protected, an attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or an attribute indicating the trustworthiness of one or more nodes within the network slice.
[0140] In step (202), the network entity can derive a slice subnet profile associated with requirements of a network slice subnet of a specific domain based on the received service profile. For example, the network entity can derive requirements of one or more entities within the network slice from attributes of the received service profiles. Based on the derived requirements and the mapping relationship of Table 1, the network entity can derive slice subnet profile(s) from the service profile. For example, the network entity can derive a top slice subnet profile from the service profile. Based on the top slice subnet profile and the mapping relationship of Table 1, the network entity can derive slice subnet profiles for each of the RAN domain, the CN domain, and the TN domain.
[0141] In step (203), the network entity may transmit the derived slice subnet profile to a network entity of a specific domain. For example, the network entity may transmit the CN slice subnet profile to a network entity within the CN (e.g., a CN NSSMF entity). The network entity may transmit the RAN slice subnet profile to a network entity within the RAN (e.g., a RAN NSSMF entity).
[0142] In one embodiment, the service profile may include at least one of: a first attribute indicating whether the network slice is protected by a particular encryption algorithm, a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or a third attribute indicating the trustworthiness of one or more nodes within the network slice.
[0143] Additionally or alternatively, the service profile may further include at least one of an attribute indicating a type of encryption algorithm to be applied to the network slice, an attribute indicating a type of authentication algorithm to be applied to the network slice, an attribute indicating a type of integrity check algorithm to be applied to the network slice, an attribute indicating a lifetime of an encryption key to be applied to the network slice, an identifier indicating a type of NEA to be applied to the network slice, or an identifier indicating a type of NIA to be applied to the network slice.
[0144] Additionally or alternatively, the service profile may further include at least one of an attribute indicating a metric for evaluating the performance of security features enabled for the network slice, an attribute indicating whether the network slice supports features for protecting privacy, or an attribute indicating whether the network slice provides resiliency.
[0145] Additionally or alternatively, the service profile may include the third attribute and may further include at least one attribute indicating one or more trusted nodes among the haul interfaces of the RAN, an attribute indicating one or more trusted entities within the RAN, or an attribute indicating one or more trusted entities within the core network.
[0146] Additionally or alternatively, the service profile may further include an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security. In one embodiment, the service profile may further include at least one of: an attribute specifying properties for protecting the network slice by a PQC algorithm, or an attribute indicating properties for protecting the network slice by a QKD algorithm.
[0147] Additionally or alternatively, the specific domain may be a RAN domain, and the service profile may further include an attribute indicating whether the N3 interface between the specific domain and the UPF is protected. In one embodiment, the service profile may further include at least one of: an attribute indicating a capability for encrypting communications over the N3 interface, an attribute indicating a capability for authenticating communications over the N3 interface, or an attribute indicating a capability for providing replay protection to the N3 interface.
[0148] Additionally or alternatively, the particular domain may be a RAN, O-RAN, or core network.
[0149] FIG. 3 illustrates a flowchart of a method (300) according to one embodiment of the present disclosure.
[0150] Referring to FIG. 3, a method (300) for generating an NSI performed by a network entity may be presented. In one embodiment, the NSMF (32) may be referred to as a network slice provisioning management service provider. In one embodiment, the RAN NSSMF (33-1), the CN NSSMF (33-2), and the TN NSSMF (33-3) may be referred to as network slice subnet provisioning management service providers.
[0151] In step (301), the CSMF (31) can acquire requirements. For example, the CSMF (31) can acquire service requirements related to a network slice, and at least some of these requirements may be related to the security of the network slice. In step (302), the CSMF (31) can map the acquired requirements to the GST and / or NEST. For example, the CSMF (31) can map requirements related to quantum security among the acquired requirements to the attribute 'quantumProtection' of the GST and / or NEST. The CSMF (31) can map security requirements specified to a specific network slice among the acquired requirements to the attribute 'securityNativeSlice' of the GST and / or NEST. The CSMF (31) can map requirements related to the supplementation of the N3 interface among the acquired requirements to the attribute 'n3Protection' of the GST and / or NEST. CSMF (31) can map requirements related to the security performance evaluation of a network slice among the acquired requirements to the 'securityPerformance' attribute of GST and / or NEST. CSMF (31) can map requirements related to trusted nodes within a network slice among the acquired requirements to the 'trustLevel' attribute of GST and / or NEST.
[0152] In step (303), the CSMF (31) may assign a service profile. For example, the CSMF (31) may assign an ID of the service profile, a Single-Network Slice Selection Assistance Information (S-NSSAI), and a Public Land Mobile Network (PLMN) ID to the service profile (or ServiceProfile IOC).
[0153] In step (304), the CSMF (31) can map the GST and / or NEST to the service profile. For example, the CSMF (31) can map the attribute 'quantumProtection' and its sub-attributes (or its associated attributes) of the GST and / or NEST to the attribute 'quantumProtection' and its corresponding sub-attribute(s) of the service profile. The CSMF (31) can map the attribute 'securityNativeSlice' and its sub-attributes (or its associated attributes) of the GST and / or NEST to the attribute 'securityNativeSlice' and its corresponding sub-attribute(s) of the service profile. The CSMF (31) can map the attribute 'N3Protection' and its sub-attributes (or its associated attributes) of the GST and / or NEST to the attribute 'N3Protection' and its corresponding sub-attribute(s) of the service profile. CSMF (31) can map the attribute 'quantumProtection' and its sub-attributes (or its associated attributes) of GST and / or NEST to the attribute 'securityPerformance' and its corresponding sub-attribute(s) of the service profile. CSMF (31) can map the attribute 'trustLevel' and its sub-attributes (or its associated attributes) of GST and / or NEST to the attribute 'trustLevel' and its corresponding sub-attribute(s) of the service profile.
[0154] In step (305), the CSMF (31) may transmit an NSI allocation request to the NSMF (32) along with a service profile. For example, the NSMF (32) may receive a service profile reflecting requirements associated with a network slice along with the NSI allocation request. The NSMF (32) has the ability to process requirements associated with a network slice (e.g., SLA information from a GST) expressed by service profile parameters. The service profile may be translated into corresponding requirements for network domains and NSSIs.
[0155] In step (306), the NSMF (32) may decide to create a new NSI. For example, if the requested NSI can be shared and an existing NSI can be used, the NSMF (32) may decide to use the existing NSI. Otherwise, the NSMF (32) may decide to create a new NSI in response to the received NSI allocation request and perform step (307). If the NSMF (32) decides to use an existing NSI, the NSMF (32) may modify the existing NSI to satisfy the requirements associated with the NSI allocation request and perform step (311).
[0156] In one embodiment, the NSMF (32) may query the NSSMF of each domain for information about the capabilities of the network slice subnet. For example, the NSMF (32) may inquire about information about delayed latency, delayed capacity (e.g., maximum number of users), etc., from each NSSMF.
[0157] In step (307), NSMF (32) can determine the NSSI to be generated from the received service profile. For example, NSMF (32) can determine the topology and configuration NSSIs of the NSI to be generated using information from the service profile.
[0158] In step (308), the NSMF (32) can derive a slice subnet profile from the service profile. For example, the NSMF (32) can derive requirements related to a network slice subnet from requirements related to a network slice reflected in the service profile based on the mapping relationship of Table 1 described above. Based on the derived requirements, the NSMF (32) can derive a slice subnet profile. For example, the NSMF (32) can derive a top slice subnet profile from the service profile, and derive a CN slice subnet profile, a RAN slice subnet profile, and a TN slice subnet profile from the derived top slice subnet profile.
[0159] In step (309), the NSMF (32) may transmit an NSSI allocation request to each domain along with a corresponding slice profile. For example, for required NSSIs (e.g., NSSIs determined in step (307)), the NSMF (32) may transmit requirements (or a slice subnet profile reflecting the requirements) associated with the corresponding network slice subnet to request allocation of the required NSSI(s) to the RAN NSSMF (33-1), CN NSSMF (33-2), and TN NSSMF (33-3). In response to the NSSI allocation request, the NSMF (32) may receive information of the allocated NSSI(s) (e.g., an administrative identifier of the NSSI, service access point information of the NSSI, external connection point information of the NSSI, etc.) from each NSSMF.
[0160] In step (310), the NSMF (32) may generate an MOI for the NSI. For example, the NSMF (32) may associate the NSSI(s) with a corresponding NSI. For example, the NSMF (32) may assign a management identifier to the NSI, associate the management identifier of the NSI with the management identifier of the received NSSI(s), and establish a connection between the service access points of the NSSI(s).
[0161] In step (311), NSMF (32) may transmit an NSI allocation response to CSMF (31). For example, NSMF (32) may inform CSMF (31) of NSI's network slice instance information (e.g., NSI's management identifier). Through steps (301 to 311), NSI may satisfy requirements related to network slices.
[0162] The method (300) is not limited to that illustrated in FIG. 3, and in one or more embodiments, the method (300) may further include steps not illustrated in FIG. 3, or some of the steps in FIG. 3 may be omitted from the method (300), or the order of some of the steps in FIG. 3 may be changed.
[0163] FIG. 4 illustrates a flowchart of a method (400) according to one embodiment of the present disclosure.
[0164] Referring to FIG. 4, a method (400) for creating a network slice subnet, performed by a first network entity of a specific domain, may be presented. In one embodiment, the method (400) of FIG. 4 may be performed by a RAN NSSMF, CN NSSMF, or TN NSSMF entity.
[0165] In step (401), the first network entity may receive a slice subnet profile associated with requirements of a network slice subnet of a domain in which the first network entity is included. In one embodiment, the slice subnet profile may include at least one of the attributes 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', or 'trustLevel' described in Table 1. For example, the slice subnet profile may include at least one of an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security, an attribute indicating whether the network slice is protected by a specific cryptographic algorithm, an attribute indicating whether an N3 interface between a RAN domain and a UPF entity is protected, an attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or an attribute indicating the trustworthiness of one or more nodes within the network slice.
[0166] In step (402), the first network entity may derive requirements associated with the network slice subnet based on the slice subnet profile. For example, the first network entity may derive requirements of one or more entities within the network slice subnet from attributes of the received slice subnet profiles.
[0167] In step (403), the first network entity may request the creation of a network function that satisfies the derived requirements from a second network entity in the domain in which the first network entity is included. For example, the first network entity may request the creation of one or more network functions based on the derived requirements (or the entire network subnet slice) along with the derived requirements from the second network entity managing the network function.
[0168] Additionally or alternatively, the slice subnet profile may include at least one of: a first attribute indicating whether the network slice is protected by a particular encryption algorithm, a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or a third attribute indicating the trustworthiness of network entities associated with the network slice.
[0169] Additionally or alternatively, the slice subnet profile may further include at least one of an attribute indicating a type of encryption algorithm to be applied to the network slice, an attribute indicating a type of authentication algorithm to be applied to the network slice, an attribute indicating a type of integrity check algorithm to be applied to the network slice, an attribute indicating a lifetime of an encryption key to be applied to the network slice, an identifier indicating a type of NEA to be applied to the network slice, or an identifier indicating a type of NIA to be applied to the network slice.
[0170] Additionally or alternatively, a slice subnet profile may further include at least one of an attribute indicating a metric for evaluating the performance of security features enabled for the network slice, an attribute indicating whether the network slice supports features for protecting privacy, or an attribute indicating whether the network slice provides resiliency.
[0171] Additionally or alternatively, the slice subnet profile may further include at least one of an attribute indicating one or more trusted nodes among the hole interfaces of the RAN, an attribute indicating one or more trusted entities within the RAN, or an attribute indicating one or more trusted entities within the core network.
[0172] Additionally or alternatively, the slice subnet profile may further include an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security. Additionally or alternatively, the slice subnet profile may further include at least one attribute indicating one or more properties for protecting the network slice by a PQC algorithm or one or more properties for protecting the network slice by a QKD algorithm.
[0173] Additionally or alternatively, the domain including the first network entity may be a RAN domain, and the slice subnet profile may further include an attribute indicating whether the N3 interface between the domain and the UPF is protected. Additionally or alternatively, the slice subnet profile may further include at least one of an attribute indicating a capability for encrypting communications over the N3 interface, an attribute indicating a capability for authenticating communications over the N3 interface, or an attribute indicating a capability for providing replay protection to the N3 interface.
[0174] Additionally or alternatively, the domain containing the first network entity may be a RAN, O-RAN, or core network.
[0175] Additionally or alternatively, the second network entity may generate configuration parameters for provisioning one or more network functions to support the network slice based on the derived requirements. For example, the second network entity may translate the derived requirements into configuration parameters for configuring each network function within the domain. The second network entity may transmit the configuration parameters to a second network entity that manages one or more network functions of the domain in which the second network entity is included. The second network entity may instantiate network functions within the domain based on the received configuration parameters and transmit the corresponding configuration parameters to each network entity within the domain.
[0176] FIG. 5 illustrates a flowchart of a method according to one embodiment of the present disclosure.
[0177] Referring to FIG. 5, a method (500) for allocating NSSI in a RAN domain, performed by network entities within the RAN domain, may be presented. In one embodiment, a RAN NSSMF (51) may be referred to as a network slice subnet provisioning management service provider. By the method (500), a new network slice subnet instance may be created, or an existing network slice subnet instance may be modified to satisfy requirements.
[0178] In step (501), the RAN NSSMF (51) may receive a request to allocate an NSSI. For example, the RAN NSSMF (51) may receive an NSSI allocation request that includes requirements associated with a network slice subnet (e.g., a RAN slice profile or a RAN slice subnet profile). In one embodiment, the NSSI allocation request may also include a query for the identity of a Network Function Virtualization Orchestrator (NFVO) to be used.
[0179] In step (502), the RAN NSSMF (51) may verify the feasibility of requirements associated with the network slice subnet. For example, the RAN NSSMF (51) may verify the feasibility of requirements to determine whether the network slice requirements can be met at a specific point in time (e.g., in terms of resources), and may optionally reserve resources that satisfy the network slice requirements.
[0180] In step (503), the RAN NSSMF (51) may determine whether to generate a new NSSI. For example, based on whether the requirements related to the received network slice subnet allow sharing of the requested NSSI and whether an existing suitable NSSI can be reused, the RAN NSSMF (51) may decide to use the existing NSSI. Otherwise, the RAN NSSMF (51) may decide to generate a new NSSI. If the existing NSSI is determined to be used, the RAN NSSMF (51) may modify the existing NSSI to satisfy the requirements related to the received network slice subnet and perform step (511). Based on the decision to generate a new NSSI, the RAN NSSMF (51) may perform step (504).
[0181] At step (504), the RAN NSSMF (51) may derive RAN requirements, network slice requirements, and / or virtualized NF (Virtual Network Function, VNF) requirements from the RAN slice subnet profile. For example, based on the received RAN slice subnet profile, the RAN NSSMF (51) may determine that a portion of the network controlled by a specific NFVO (e.g., NFVO (53)) should be included to satisfy the NSSI requirements. The RAN NSSMF (51) may determine requirements related to the network slice (e.g., information about the target Network Slice Descriptor (NSD) and additional parameterization for the specific network slice to be instantiated, etc.).
[0182] At step (505), the RAN NSSMF (51) may request the NFVO and / or Cloud-Native Network Function (CNF) Orchestrator (CNFO) (53) to instantiate a network slice. For example, based on network slice-related requirements, the RAN NSSMF (51) may trigger the instantiation of a network slice to the NFVO and / or CNFO (53). In response to the request from the RAN NSSMF (51), the NFVO and / or CNFO (53) may generate an ID of a network slice, instantiate the network slice, and notify the RAN NSSMF (51) that the instantiation of the network slice is complete.
[0183] In step (506), the RAN NSSMF (51) may perform an NSSI allocation procedure. For example, the RAN NSSMF (51) may map the NSI to a corresponding NSSI. The RAN NSSMF (51) may allocate a management identifier of the NSSI and map the NSI to the corresponding management identifiers.
[0184] In step (507), the RAN NSSMF (51) may request the creation of one or more NFs from the Network Function Management Function (NFMF) (52). For example, to configure NSSI components that satisfy network slice requirements, the RAN NSSMF (51) may use the NF provisioning service of the NFMF (52).
[0185] At step (508), the NFMF (52) may instantiate the VNF and / or CNF through the VNF Manager (VNFM) and / or the CNF Manager (CNFM) (54). For example, the NFMF (52) may scale the requirements of the VNF and / or CNF through the VNFM and / or the CNFM (54) based on an NF creation request from the RAN NSSMF (51), instantiate the VNF and / or CNF based on the requirements of the VNF and / or CNF, and notify the RAN NSSMF (51) that the instantiation of the VNF and / or CNF is complete.
[0186] In step (509), the NFMF (52) may configure MOIs of the NF. For example, the NFMF (52) may configure MOIs for entities of the Centralized Unit-Control Plane (CU-CP) (55-1), the CU-User Plane (CU-UP) (55-2), and the Distributed Unit (DU) (55-3). The MOIs may be configured based on configuration parameters translated from the RAN slice subnet profile.
[0187] In step (510), the NFMF (52) may configure the CU-CP (55-1), the CU-UP (55-2), and the DU (55-3). For example, the NFMF (52) may provide configuration data related to a network slice to a corresponding entity. In one embodiment, the configuration data provided by the NFMF (52) may include configuration parameters corresponding to at least some or all of the attributes 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', or 'trustLevel' described in Table 1, and any combination of their respective sub-attributes. Based on the configuration parameters provided by the NFMF (52), the CU-CP (55-1), the CU-UP (55-2), and the DU (55-3) may be configured.
[0188] In step (511), the NFMF (52) may transmit a response to the NF creation request to the RAN NSSMF (51). For example, the NFMF (52) may transmit the DNs of the MOIs of the NFs along with a notification that the NF creation has been completed to the RAN NSSMF (51).
[0189] In step (512), the RAN NSSMF (51) may transmit an NSSI allocation response. For example, the RAN NSSMF (51) may transmit information related to the NSSI, such as an identifier of the NSSI, to the NSMF.
[0190] In one embodiment, the NFMF (52) may be implemented as an Element Management System (EMS).
[0191] In one embodiment, life cycle management (LCM) of network slices may be performed to satisfy TN requirements. In one embodiment, virtual links (VLs) may be configured between VNFs. For example, VLs may be configured with Virtual Local Area Networks (VLANs) that satisfy bandwidth requirements. In one embodiment, a VL (e.g., Virtual Routing and Forwarding (VRF) and / or Segment Routing (SR)) on the backhaul (BH) or backbone (BB) side that satisfies TN requirements (e.g., bandwidth, latency, etc.) may be mapped to a VLAN on the NF side. In one embodiment, for the RAN domain, a Data Center Software Defined Network (DC-SDN), a Leaf / Spine switch, and a Border Gateway (GW) may be additionally configured. TN requirements may be configured for the DC-SDN, the Leaf / Spine switch, and the Border Gateway (GW).
[0192] As steps (501 to 512) are performed, the attributes described in Table 1 in the service profile may be set in the RAN domain. The RAN NSSMF may perform an NSI creation procedure through the NFMF based on the RAN slice profile (or RAN slice subnet profile) received from the CSMF or NSMF. At this time, the attributes described in Table 1 may be transmitted through the RAN slice profile (or RAN slice subnet profile). When the NFMF performs a configuration procedure of NFs such as CU-CP, CU-UP, and DU of the RAN, the NFMF may use configuration data (or configuration parameters) corresponding to the attributes described in Table 1 translated from the RAN slice subnet profile to create a security-enhanced RAN network slice.
[0193] The method (500) is not limited to that illustrated in FIG. 5, and in one or more embodiments, the method (500) may further include steps not illustrated in FIG. 5, or some of the steps in FIG. 5 may be omitted from the method (500), or the order of some of the steps in FIG. 5 may be changed.
[0194] FIG. 6 illustrates a flowchart of a method (600) according to one embodiment of the present disclosure.
[0195] Referring to FIG. 6, a method (600) for allocating an NSSI in a CN domain, performed by network entities within the CN domain, may be presented. In one embodiment, the CN NSSMF (61) may be referred to as a Network Slice Subnet Provisioning Management Service Provider or a Network Slice Subnet Management Service Provider (NSSM_SP). By the method (600), a new network slice subnet instance may be created, or an existing network slice subnet instance may be modified to satisfy requirements.
[0196] In step (601), the CN NSSMF (61) may receive a request to allocate an NSSI. For example, the CN NSSMF (61) may receive an NSSI allocation request that includes requirements associated with a network slice subnet (e.g., a CN slice subnet profile or a CN slice subnet profile). In one embodiment, the NSSI allocation request may also include a query for the identity of the NFVO to be used.
[0197] In step (602), the CN NSSMF (61) can verify the feasibility of requirements associated with the network slice subnet. Step (602) can be performed in a similar manner to step (502) of FIG. 5.
[0198] In step (603), the CN NSSMF (61) may determine whether to create a new NSSI. Step (603) may be performed in a similar manner to step (503) of FIG. 5. If it is determined that an existing NSSI is to be used, the CN NSSMF (61) may modify the existing NSSI to satisfy requirements related to the received network slice subnet, and may perform step (611). Based on the decision to create a new NSSI, the CN NSSMF (61) may perform step (604).
[0199] In step (604), the CN NSSMF (61) may derive TN requirements, network slice requirements, and / or CNF requirements from the CN slice subnet profile. Step (604) may be performed in a similar manner to step (504) of FIG. 5.
[0200] In step (605), CN NSSMF (61) may request instantiation of a network slice with NFVO and / or CNFO (63). Step (605) may be performed in a similar manner to step (505) of FIG. 5.
[0201] In step (606), the CN NSSMF (61) may perform an NSSI assignment procedure. For example, the CN NSSMF (61) may map the NSI to a corresponding NSSI. Step (606) may be performed in a similar manner to step (506) of FIG. 5.
[0202] In step (607), the CN NSSMF (61) may request the NFMF (62) to create one or more NFs. Step (607) may be performed in a similar manner to step (507) of FIG. 5.
[0203] In step (608), NFMF (62) may instantiate VNF and / or CNF through VNFM and / or CNFM (64). Step (608) may be performed in a similar manner to step (508) of FIG. 5.
[0204] In step (609), the NFMF (62) can configure the MOI of the NF. Step (609) can be performed in a similar manner to step (509) of FIG. 5.
[0205] In step (610), the NFMF (62) may configure network entities (65-1 to 65-6) within the CN network. Step (610) may be performed in a similar manner to step (510) of FIG. 5.
[0206] In step (611), the NFMF (62) may transmit a response to the NF creation request to the CN NSSMF (61). Step (611) may be performed in a similar manner to step (511) of FIG. 5.
[0207] In step (612), the CN NSSMF (61) may transmit an NSSI allocation response. Step (612) may be performed in a similar manner to step (512) of FIG. 5.
[0208] In one embodiment, the NFMF (62) may be implemented as an Element Management System (EMS).
[0209] In some embodiments, life cycle management (LCM) of network slices may be performed to satisfy TN requirements. In some embodiments, virtual links (VLs) may be configured between VNFs. For example, VLs may be configured with Virtual Local Area Networks (VLANs) that satisfy bandwidth requirements. In some embodiments, a VL (e.g., VRF and / or SR) on the BH or BB side that satisfies TN requirements (e.g., bandwidth, latency, etc.) may be mapped to a VLAN on the NF side. In one embodiment, for the CN domain, a DC-SDN, a leaf / spine switch, and a border GW may be additionally configured. TN requirements may also be configured for the DC-SDN, the leaf / spine switch, and the border GW of the CN domain.
[0210] As steps (601 to 612) are performed, the attributes described in Table 1 in the service profile may be set in the CN domain. The CN NSSMF may perform an NSI creation procedure through the NFMF based on the CN slice profile (or CN slice subnet profile) received from the CSMF or NSMF. At this time, the attributes described in Table 1 may be delivered through the CN slice profile (or CN slice subnet profile). When performing a configuration procedure of NFs such as the Unified Data Management (UDM) of the CN, the Policy Control Function (PCF), the Network Slice Selection Function (NSSF), the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the UPF, the NFMF may use the configuration data (or configuration parameters) corresponding to the attributes described in Table 1 translated from the CN slice subnet profile to create a security-enhanced CN network slice.
[0211] The method (600) is not limited to that illustrated in FIG. 6, and in one or more embodiments, the method (600) may further include steps not illustrated in FIG. 6, or some of the steps in FIG. 6 may be omitted from the method (600), or the order of some of the steps in FIG. 6 may be changed.
[0212] FIG. 7 illustrates a flowchart of a method (700) according to one embodiment of the present disclosure.
[0213] Referring to FIG. 7, a method (700) for creating a network slice subnet, performed by a first network entity, may be presented. In one embodiment, the method (700) of FIG. 7 may be performed by an NFMF of a RAN domain or an NFMF of a CN domain.
[0214] In step (701), a first network entity may receive a request from a second network entity to create a network function associated with a network slice. For example, the first network entity may receive a request from the NSSMF of the corresponding domain to create a network function for configuring a network slice. In step (702), the first network entity may provision one or more configuration parameters generated based on requirements for the network slice to a network entity for performing the network function.
[0215] In one embodiment, the one or more configuration parameters provisioned by the first network entity may include at least one of: one or more parameters relating to a first attribute indicating whether the network slice is protected by a particular cryptographic algorithm, one or more parameters relating to a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or one or more parameters relating to a third attribute indicating trustworthiness of network entities associated with the network slice.
[0216] In one embodiment, the one or more configuration parameters provisioned by the first network entity may further include one or more parameters relating to properties for the network slice to be protected by a cryptographic algorithm for quantum security.
[0217] In one embodiment, the first network entity and the second network entity are included in a RAN domain, and one or more configuration parameters provisioned by the first network entity include: one or more configuration parameters further including: one or more parameters relating to properties for protecting an N3 interface between the RAN domain and the UPF.
[0218] One or more configuration parameters provisioned by the first network entity may be converted from a network slicing (subnet) profile for the domain in which the first network entity is included. For example, the properties listed in Table 1 included in the network slicing (subnet) profile may be converted into parameters that must be set for each network function to create a network slice.
[0219] FIG. 8 illustrates a flowchart of a method (800) according to one embodiment of the present disclosure.
[0220] Referring to FIG. 8, a method (800) for enhanced security network slicing in a RAN domain based on the attribute 'quantumProtection' among the attributes described in Table 1 may be presented. According to the method (800), a network slice may be set in a RAN domain based on the attribute 'quantumProtection'.
[0221] In step (801), the CSMF and / or NSMF (81) may request the RAN NSSMF (82) to create a quantum-safe slice. The request may include a slice subnet profile for the RAN domain. Through the slice subnet profile, an SLA for the quantum-safe network slice may be communicated to the RAN NSSMF (82). In the illustrated embodiment, the slice subnet profile may include multiple attributes. For example, the slice subnet profile may indicate a target cell coverage area such as tracking area A, B, C, etc., an SLA including a throughput with an average of 10 Mbps and an availability of 90%, an SLA monitoring window having a short window of 10 seconds and a long window of 15 minutes, an isolation level having a high isolation level, a medium isolation level, and a low isolation level, and an attribute related to quantum safety (e.g., the attribute 'quantumProtection'). Quantum security related properties may include sub-properties indicating whether the network slice is protected or not, and sub-properties indicating the quantum encryption algorithm (e.g., PQC, QKD, or a combination thereof, or other quantum encryption algorithm) to be used for the network slice. In one embodiment, the quantum security related properties may include at least some of the sub-properties of the 'quantumProtection' property set forth in Table 3.
[0222] In step (802), the RAN NSSMF (82) may request the RAN NFMF (83) to confirm the feasibility. The RAN NSSMF (82) may perform the feasibility check through the RAN NFMF (83) to create a network slice that satisfies the received SLA. For example, the RAN NSSMF (82) may check the SLA availability range. The RAN NSSMF (82) may check the feasibility by considering the bandwidth, the sum of the SLAs of the pre-existing slices, etc. For example, the RAN NSSMF (82) may check the feasibility of quantum security based on an attribute indicating whether QKD is supported.
[0223] In one embodiment, the RAN NFMF (83) may be implemented as an EMS, implemented as OpenStack, or implemented as Kubernetes (or K8s).
[0224] At step (803), the RAN NSSMF (82) can select a feature set and transform parameters through the RAN NFMF (83). For example, the RAN NFMF (83) selects features and generates configuration parameters to configure RAN NFs according to a slice subnet profile. The RAN NFMF (83) can select features such as a minimum bit rate, a slice-aware load balancer (LB), physical resource block (PRB) portion partitioning, and PRB portion automatic configuration based on the slice subnet profile. The RAN NFMF (83) can derive parameters for configuring CU-CP, CU-UP, and DU based on the selected features and the slice subnet profile. In one embodiment, the RAN NFMF (83) may perform parameter transformation based on at least some of the specified algorithm type, authentication algorithm type, encryption algorithm type, integrity check algorithm type and encryption key setting indicated by the attribute 'quantumProtection' and its sub-attributes in the slice subnet profile.
[0225] In step (804), the RAN NFMF (83) can configure the CU-CP (84-1), the CU-UP (84-2), and the DU (84-3) based on the parameters converted in step (803). For example, the RAN NFMF (83) can set a slice-aware LB by setting configuration parameters corresponding to target throughput, threshold, reporting cycle, LB policy, etc. for the CU-UP (84-1). The RAN NFMF (83) can set a slice-aware LB by setting configuration parameters corresponding to target throughput, violation decision condition, etc. for the DU (84-3), set a minimum bitrate by setting configuration parameters for setting the target throughput to the level of a Transmission Time Interval (TTI), and set a PRB partial auto-configuration by setting configuration parameters for setting the target throughput to 15 minutes.
[0226] The RAN NFMF (83) may set the converted configuration parameters to the PDCP (Packet Data Convergence Protocol) entity (or layer) of the CU-UP based on at least some of the parameters related to a quantum-safe slice among the converted parameters, for example, the specified algorithm type, authentication algorithm type, encryption algorithm type, integrity check algorithm type, and encryption key setting indicated by the attribute 'quantumProtection' and its sub-attributes in the slice subnet profile. Accordingly, a user data encryption function using a quantum encryption algorithm (e.g., a PQC algorithm) may be provided for the network slice. For example, communication within the RAN domain of the network slice may be encrypted with a PQC cipher suite configured for the CU-CP based on the slice subnet profile.
[0227] The method (800) is not limited to that illustrated in FIG. 8, and in one or more embodiments, the method (800) may further include steps not illustrated in FIG. 8, or some of the steps in FIG. 8 may be omitted from the method (800), or the order of some of the steps in FIG. 8 may be changed.
[0228] FIG. 9 illustrates network slices (910, 920) according to one embodiment of the present disclosure.
[0229] Referring to FIG. 9, a first network slice (910) and a second network slice (920) implemented based on the attribute 'securityNativeSlice' may be presented. The first network slice (910) and the second network slice (920) may be different from each other. For example, the first network slice (910) may be a URLLC slice, and the second network slice (920) may be an eMMB slice. An identifier (e.g., S-NSSAI) of the first network slice (910) and an identifier of the second network slice (920) may be different from each other. The UE (901) may communicate with the data network (930) using the network slices (910, 920). In one embodiment, based on the attribute 'securityNativeSlice', when one UE (901) uses multiple network slices (910, 920), the security policy can be set differently between different network slices (910, 920).
[0230] To configure the first network slice (910), the NSC may request the NSP to create an NSI based on the attribute 'securityNativeSlice'. The NSP may perform an NSI feasibility check and provide the NSC with an NSI that satisfies the requested attribute 'securityNativeSlice' by creating a new NSI or modifying an existing NSI. NF configuration information (e.g., information for configuring the SMF (911) and UPF (912) of the first network slice (910)) may be provided to the NFVO (or K8s) and / or the NFMF (or EMS) by the NSSMF(s) of the first network slice (910). In one embodiment, configuration parameters generated based on the attribute 'securityNativeSlice' and its sub-attributes (e.g., at least some of the sub-attributes described in Table 6) can be set for an entity (e.g., a PDCP entity) within a CU-CP within a first network slice (910). For example, the configuration parameters described above can be set to a PDCP entity of a CU-CP entity within the first network slice (919) via an NRCellCU IOC.
[0231] In a similar manner, a second network slice (920) can be created based on the attribute 'securityNativeSlice' having a different value than the attribute 'securityNativeSlice' of the first network slice (910). NFs of the second network slice (920), for example, SMF (921) and UPF (922), can be configured based on the attribute 'securityNativeSlice' for the second network slice (920).
[0232] Base stations (902, 923) can communicate with network slices (910, 920) via AMF (904). Base stations (902, 923) can derive a security context for each network slice. For example, communication for a first network slice (910) can be encrypted by a first security key (91), and the first security context (91) can be dedicated to the first network slice (910). Communication for a second network slice (920) can be encrypted by a second security key (92), and the second security context (92) can be dedicated to the second network slice (920). Accordingly, the NSC can provide enhanced security as a service (NSaaS) to the UE (901). For example, the RAN domain of the first network slice (910) and the RAN domain of the second network slice (920) may have different security contexts, so that even if the security key of one slice is leaked or a horizontal attack occurs between network slices, the security of the other slice can still be maintained. Accordingly, the security of the communication of the first network slice (910) and the communication of the second network slice (920) can be strengthened.
[0233] FIG. 10 illustrates network entities according to one embodiment of the present disclosure.
[0234] Referring to FIG. 10, a network slice may be configured in an Open-RAN (O-RAN) domain. For example, the RAN (1031-3) of FIG. 10 may be associated with an O-RAN, or implemented as at least a portion of an O-RAN. In the embodiment of FIG. 10, an Operations Support System / Business Support System (OSS / BSS) portal (1010) may acquire GST and / or NEST defined by the GSMA. Based on the acquired GST and / or NEST, the OSS / BSS portal (1010) may provide a service profile to an E2E (end-to-end) service orchestration (1020). In one embodiment, the service profile may include at least some of the attributes in the 'Service Profile Attributes' column described in Table 1. The E2E (end-to-end) service orchestration (1020) can derive a slice profile (e.g., a top slice subnet profile) based on a service profile from the OSS / BSS portal (1010). The E2E (end-to-end) service orchestration (1020) can derive slice (subnet) profiles (e.g., a RAN slice subnet profile, a TN slice subnet profile, and a CN slice subnet profile) for the RAN domain, the TN domain, and the CN domain based on the slice subnet profile. The E2E (end-to-end) service orchestration (1020) can send the RAN slice subnet profile to the RAN domain orchestration (1031), the TN slice subnet profile to the TN domain orchestration (1032), and the CN slice subnet profile to the CN domain orchestration (1033). Orchestrations (1031, 1032, 1033) may be entities that manage corresponding domains.
[0235] The RAN NSSMF (1031-1) may configure a network slice for the RAN (1031-3) based on the RAN slice subnet profile. For example, the RAN NSSMF (1031-1) may derive requirements for a RAN subnet slice from the RAN slice subnet profile based on the method (400) of FIG. 4 and the method (500) of FIG. 5, and may allocate instances for the RAN subnet slice based on the derived requirements. The RAN NFMF (1031-2) may obtain the RAN slice subnet profile from the RAN NSSMF (1031-1), convert configuration parameters for the RAN (1031-3) based on the obtained profile, and provision the converted RAN configuration parameters to network entities of the RAN (1031-1). Accordingly, a network slice for the RAN (1031-1) may be configured. In a similar manner, a network slice may be set up for TN (1032-3) based on TN configuration parameters converted from a TN slice subnet profile by TN NSSMF (1032-1) and TN NFMF (1032-2). A network slice may be set up for CN (1033-3) based on CN configuration parameters converted from a CN slice subnet profile by CN NSSMF (1033-1) and CN NFMF (1033-2) based on method (400) of FIG. 4 and method (600) of FIG. 6.
[0236] The O-Cloud (1031-4) may be a cloud computing platform (or entity) that manages virtualization of O-RAN nodes, such as a near-real-time (near-RT) RAN Intelligence Controller (RIC) (1031-6), an Open-CU (O-CU), an Open-DU (O-DU), and an Open-Radio Unit (O-RU) (O-RU). The non-near-RT RIC (1031-5) may be an entity for automating the network using artificial intelligence / machine learning (AI / ML). For example, the non-near-RT RIC (1031-5) may optimize the O-RAN and control the O-RAN nodes using data collected from external servers and / or RAN nodes (e.g., network entities within or associated with the RAN (1031-3). The non-real-time RIC (1031-5) can generate and provide AI / ML models or policies used by the near-real-time RIC (1031-6). The non-real-time RIC (1031-5) can include one or more non-real-time RIC applications (rAPPs). The rAPPs can provide services related to the operation of the O-RAN. The near-real-time RIC (1031-6) can control RAN nodes and optimize radio resources based on the AI / ML models and policies provided from the non-real-time RIC (1031-5). In one embodiment, the near-real-time RIC (1031-6) can include one or more near-real-time RIC applications (xAPPs).
[0237] The RAN NSSMF (1031-1) can forward the RAN slice subnet profile to the O-Cloud (1031-4). The O-Cloud (1031-4) can manage the virtualization of nodes within the O-RAN. For example, the O-Cloud (1031-4) can convert configuration parameters for the O-RAN based on the RAN slice subnet profile from the RAN NSSMF (1031-1). Based on the converted ORAN configuration parameters, the O-Cloud (1031-4) can set properties for the network slice in the O-RAN nodes (or network entities) (e.g., the near-real-time RIC (1031-6)).
[0238] According to the embodiment illustrated in FIG. 10, a network slice may be configured for an O-RAN based on a service profile that includes at least some of the attributes described in Table 2. Accordingly, a network slice with enhanced security, as described above, may be provided for the O-RAN domain as well.
[0239] FIGS. 11A and 11B illustrate network entities according to one embodiment of the present disclosure.
[0240] FIG. 11a illustrates an example of monitoring security performance in a network slice configured based on the attribute 'securityPerformance' for a typical RAN domain (e.g., a RAN domain defined by 3GPP). Referring to FIG. 11a, a RAN NSSMF (1110a) may configure a network slice in a RAN domain based on a slice subnet profile for the RAN domain (e.g., a RAN slice subnet profile). For example, the slice subnet profile for the RAN domain may include the attribute 'securityPerformance' or at least one of the sub-attributes of the attribute 'securityPerformance' described in Table 10. Based on the slice subnet profile for the RAN domain, entities (e.g., an SLA assurance function (1120a), a DU (1131a), a CU-UP (1132a), and / or a CU-CP (1133a)) may be configured.
[0241] After a network slice is set based on the attribute 'securityPerformance', the RAN NSSMF (1110a) can continuously perform performance monitoring for SLA satisfaction based on the set attribute 'securityPerformance'. For example, the RAN NSSMF (1110a) can include a closed-loop SLA assurance (or closed-loop SLA assurance function) (1111a) (or an entity that performs this function). The closed-loop SLA assurance function (1111a) can guarantee the level of communication service based on a closed loop consisting of monitoring, analysis, decision, and execution steps. By the closed-loop SLA assurance function (1111a), resources used for communication services within the network slice can be dynamically controlled to satisfy the SLA and not violate the SLA.
[0242] The closed-loop SLA assurance function (1111a) can convey SLA requirements to the SLA assurance function (1120a) of the RAN domain via a slice subnet profile. For example, the SLA requirements can convey requirements such as throughput, latency, and security. In one embodiment, the slice subnet profile can include the attribute 'secPerfList' as a sub-attribute of the attribute 'securityPerformance'. The slice subnet profile can include at least one of the attributes 'secPerfId', 'secPerfType', 'privacySupport', or 'resiliencySupport' described in Table 11 as a sub-attribute of the attribute 'secPerfList'. Based on the sub-attribute(s) of the attribute 'secPerfList', the SLA Assurance function (1120a) can instruct the functions (1140a) that monitor the performance of the DU (1131a), the CU-CP (1132a), and the CU-CP (1133a) to perform SLA fulfillment reporting. The functions (1140a) can monitor the indicator(s) indicated by the sub-attribute(s) of 'secPerfList'. For example, indicator(s) such as overhead measurement, privacy protection function, resilience evaluation measurement, etc. can be indicated as security performance evaluation indicators by the sub-attribute(s) of 'secPerfList'. The functions (1140a) can provide an SLA fulfillment report to the closed-loop SLA Assurance (1111a) of the RAN NSSMF (1110a) based on these indicator(s). For example, an SLA compliance report may include information related to Fault, Configuration, Accounting, Performance, and Security (FCAPS).Security-related information in the SLA compliance report may be based on security performance measured by indicators indicated by sub-attributes of 'secPerfList'. Based on the reports provided by the functions (1140a), the closed-loop SLA assurance function (1111a) may monitor security performance and adjust resources in the RAN domain to maintain satisfaction of SLA requirements.
[0243] FIG. 11b illustrates an example of monitoring security performance in a network slice configured based on the attribute 'securityPerformance' for the O-RAN domain. Referring to FIG. 11b, the RAN NSSMF (1110b) may be implemented in a manner similar to the RAN NSSMF (1110a) of FIG. 11a and may operate in a manner similar to the RAN NSSMF (1110a).
[0244] After a network slice based on the attribute 'securityPerformance' is configured for the O-RAN, the RAN NSSMF (1110b) can continuously perform performance monitoring for SLA satisfaction based on the configured attribute 'securityPerformance'. For example, the RAN NSSMF (1110b) can monitor the performance of the O-RAN network subnet slice for SLA satisfaction by the closed-loop SLA assurance function (1111b).
[0245] The closed-loop SLA assurance function (1111b) can convey SLA requirements to the rAPP (1121b) for SLS assurance of the non-near real-time RIC (1120b) via a slice subnet profile. For example, the SLA requirements can convey requirements such as throughput, latency, and security. In one embodiment, the slice subnet profile can include the attribute 'secPerfList' as a sub-attribute of the attribute 'securityPerformance'. The slice subnet profile can include at least one of the attributes 'secPerfId', 'secPerfType', 'privacySupport', or 'resiliencySupport' described in Table 11 as a sub-attribute of the attribute 'secPerfList'. Based on the sub-attribute(s) of the attribute 'secPerfList', the rAPP (1121b) can convey SLA requirements to the xAPP (1131b) for SLA assurance of the near-real-time RIC (1130b) via the A1 interface. The xAPP (1131b) can instruct the functions (1150b) that monitor the performance of the DU (1141b), the CU-CP (1142b), and the CU-CP (1143b) to perform SLA compliance reporting via the E2 interface. The functions (1150b) can monitor the indicator(s) indicated by the sub-attribute(s) of 'secPerfList'. For example, indicator(s) such as overhead measurement, privacy protection function, and resilience evaluation measurement can be indicated as security performance evaluation indicators by the sub-attribute(s) of 'secPerfList'. The functions (1150b) may provide SLA compliance reports based on these indicators to the closed-loop SLA assurance (1111b) of the RAN NSSMF (1110b) via the O1 interface. For example, the SLA compliance report may include information related to FCAPS.Security-related information in the SLA compliance report may be based on security performance measured by indicators indicated by sub-attributes of 'secPerfList'. Based on the reports provided by the functions (1150b), the closed-loop SLA assurance function (1111b) may monitor security performance and adjust resources in the O-RAN domain to maintain satisfaction of SLA requirements.
[0246] In the embodiments illustrated in Figures 11a and 11b, by assigning the "securityPerformance" attribute to the slice subnet profile, security performance-related monitoring can be enabled in both the general RAN domain and the O-RAN domain. For example, the RAN NSSMF can continuously perform performance monitoring for SLA satisfaction based on sub-attributes of the "securityPerformance" attribute. Accordingly, the security performance of the enhanced network slice can be continuously guaranteed.
[0247] In one embodiment, security performance-related monitoring may be performed in the CN domain in a manner similar to the embodiment illustrated in FIG. 11a. For example, the CN NSSMF may configure network entities within the CN domain based on sub-attributes of the attribute 'securityPerformance', in a manner similar to the RAN NSSMF (1110a) illustrated in FIG. 11a, and continuously perform performance monitoring for SLA satisfaction based on SLA satisfaction reports from these functions.
[0248] FIG. 12 illustrates a block diagram of a network infrastructure (1220) according to one embodiment of the present disclosure.
[0249] Referring to FIG. 12, a first network slice (1200-1) and a second network slice (1200-2) may be configured by an orchestrator (1210) on a network infrastructure (1220). The orchestrator (1200) may include an E2E service orchestration (1211) including a RAN NSSMF (1211-1), a CN NSSMF (1211-2), and a TN NSSMF (1211-3). The E2E service orchestration (1211) may obtain a service profile based on SLA requirements for the first network slice (1200-1), and generate slice (subnet) profiles for the RAN domain, the CN domain, and the TN domain based on the obtained service profile. The RAN NSSMF (1211-1), CN NSSMF (1211-2), and TN NSSMF (1211-3) may configure a first network slice (1200-1) for entities in the RAN domain, entities in the CN domain, and entities in the TN domain based on slice (subnet) profiles for the RAN domain, CN domain, and TN domain, respectively. In a similar manner, a second network slice (1200-2) may be configured by the E2E service orchestration (1211), RAN NSSMF (1211-1), CN NSSMF (1211-2), and TN NSSMF (1211-3).
[0250] The first network slice (1200-1) and the second network slice (1200-2) may share at least some of the network entities on the network infrastructure (1220) to connect to the data network (DN) (1240-1) and the DN (1240-2), respectively. For example, the RU (1221), the DU (1222), and the fronthaul TN between the RU (1221) and the DU (1222) may be shared by both the first network slice (1200-1) and the second network slice (1200-2). When the network slices (1200-1, 1200-2) are configured on the O-RAN domain, the near-real-time RIC (1223) may also be shared by the network slices (1200-1, 1200-2). Network slices (1200-1, 1200-2) can share the Radio Resource Control (RRC) entity of the CU-CP. Network slices (1200-1, 1200-2) can share the AMF (1226), the Authentication Server Function (AUSF) (1228), the Network Repository Function (NRF) (1229), the UDM (1230), and the NSSF (1232) of the CN.
[0251] The PDCP entity (1225-1), UPF (1227-1), PCF (1231-1), and SMF (1233-1) of the CU-UP of the first network slice (1200-1) may be dedicated to the first network slice (1200-1). Alternatively, the first network slice may share at least some of the aforementioned entities with other network slices.
[0252] The PDCP entity (1225-2), UPF (1227-2), PCF (1231-2) and SMF (1233-2) of the CU-UP of the second network slice (1200-2) may be dedicated to the second network slice (1200-2). In one embodiment, the service profile for the second network slice (1200-2) may include at least one of the attributes 'qauntumProtection', 'securityNativeSlice', 'n3Protection', 'securityPerformance', or 'trustLevel'.
[0253] Based on the attribute 'qauntumProtection' included in the service profile for the second network slice (1200-2), a configuration related to an algorithm for quantum security can be set for the PDCP entity (1225-2) of the CU-UP of the second network slice (1200-2) by the method (800) of FIG. 8. Accordingly, an encryption algorithm for quantum security can be applied to the midhaul TN, backhaul TN (e.g., n3 interface), and backbone (e.g., n6 interface) for the second network slice (1200-2).
[0254] Based on the attribute 'securityNativeSlice' included in the service profile for the second network slice (1200-2), a different security key may be applied to the communication associated with the second network slice (1200-2) than that of the first network slice (1200-1), as described with reference to FIG. 9.
[0255] Based on the attribute 'n3Protection' included in the service profile for the second network slice (1200-2), the n3 interface between the PDCP entity (1225-2) of the CU-UP of the second network slice (1200-2) and the UPF (1227-2) may be protected. For example, for communication over the n3 interface between the PDCP entity (1225-2) of the CU-UP of the second network slice (1200-2) and the UPF (1227-2), an encryption algorithm, an authentication algorithm, and / or replay protection indicated by the attribute 'n3Protection' may be applied.
[0256] Based on the attribute 'securityPerformance' included in the service profile for the second network slice (1200-2), the security performance of the second network slice (1200-2) can be continuously monitored as described with reference to FIGS. 11a and 11b.
[0257] Based on the attribute 'trustLevel' included in the service profile for the second network slice (1200-2), only trusted nodes may be used for communications requiring high security by the NSC. For example, based on the control of the NSP or the control of the entity managing the network slice of the network infrastructure (1220), only trusted network nodes within the second network slice (1200-2) may be used for communications with the second network slice (1200-2), either temporarily or permanently. For example, only nodes (or devices) in the fronthaul TN, nodes (or devices) in the midhaul TN, nodes (or devices) in the backhaul TN, NF entities in the RAN domain, and / or NF entities in the CN domain, which are indicated as trusted by the attribute 'trustLevel', may be selected for communications or configuration of the second network slice (1200-2).
[0258] Network slices can be configured for various target services. Depending on security needs, a security-enhanced network slice, such as the second network slice (1200-2), may be provided. For example, a network slice, such as the second network slice (1200-2), may be implemented for security-critical industries such as government agencies, military communications, medical services, and financial services. As described above, a security-enhanced network slice can be provided based on the properties presented in Table 1. Referring to the embodiment of FIG. 12, a security-enhanced network slice can be provided while utilizing at least some of the existing equipment (or existing entities) of the network infrastructure (1220).
[0259] In one embodiment, the properties presented in Table 1 can also be applied to Intent Based Networking (IBN). For example, the properties presented in Table 1 can be reflected in intent expectations for intent-derived network slice management, such as intent expectations for delivering objects related to networks and services, and intent expectations for object performance related to networks and services. In one embodiment, the 'expectation object' of a user's intent can be a network slice, and the target, condition, and value of the user's intent can be set to correspond to any one of the properties presented in Table 1. Those skilled in the art will understand that a network slice can be set in an IBN based on a set of such intents, based on at least some of the properties presented in Table 1.
[0260] FIG. 13 illustrates a block diagram of a network entity (1300) according to one embodiment of the present disclosure.
[0261] Referring to FIG. 13, a network entity (1300) may include a processor (1310) and a memory (1320). In one embodiment of the present disclosure, the network entity (1300) may be implemented as any one of a CSMF, an NSMF, a RAN NSSMF, a CN NSSMF, a TN NSSMF, an NFMF, an NFVO, a CNFO, a VNFM, a CNFM, a RU, a CU-CP, a CU-UP, a DU, a UDM, a PCF, a NSSF, an AMF, an SMF, a UPF, an O-Cloud, a non-near real-time RIC, a near real-time RIC, an orchestrator, or an E2E service orchestration. In one embodiment of the present disclosure, the network entity (1300) may be implemented as a subordinate entity of any of the entities described above (e.g., an RRC entity of CU-CP, a PDCP entity of CU-UP, etc.). In one embodiment of the present disclosure, the network entity (1300) may be implemented as one network entity that performs at least some of the operations described above with reference to FIGS. 1 to 12.
[0262] In one embodiment of the present disclosure, the network entity (1300) may include, but is not limited to, at least one processor (1310) and a memory (1320). The processor (1310) may be electrically connected to components included in the network entity (1300) and may perform operations or data processing related to control and / or communication of the components included in the network entity (1300). In one embodiment of the present disclosure, the processor (1310) may load and process requests, commands, or data received from at least one of the other components into the memory, and store the processing result data in the memory (1320).
[0263] According to various embodiments, one or more processors included in the processor (1310) may be circuitry such as a System on Chip (SoC), an Integrated Circuit (IC), etc. The processor (1310) may include at least one of circuitry such as a general-purpose processor such as a central processing unit (CPU), an application processor (AP), a digital signal processor (DSP), a graphics-only processor such as a graphics processing unit (GPU), a vision processing unit (VPU), or an artificial intelligence-only processor such as a neural processing unit (NPU). When one or more processors included in the processor (1310) are artificial intelligence-only processors, the artificial intelligence-only processor may be designed with a hardware structure specialized for processing a specific artificial intelligence model.
[0264] The processor (1310) can be controlled to process input data according to predefined operation rules, algorithms, methods, or models stored in the memory (1320). The processor (1310) can be controlled to process input data based on data stored in the memory (1320). The processor (1310) can perform operations of predefined operation rules, algorithms, methods, or models stored in the memory (1320) using the input data. The processor (1310) can process data according to predefined operation rules or artificial intelligence models by executing a program or at least one instruction stored in the memory (1320).
[0265] The memory (1320) is electrically connected to the processor (1310) and may store one or more modules, algorithms, operating rules, models, programs, instructions, or data related to the operation of components included in the network entity (1300). For example, the memory (1320) may store one or more modules, algorithms, operating rules, models, programs, instructions, or data for processing and controlling the processor (1310). The memory (1320) may include at least one type of storage medium among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a RAM (Random Access Memory), a SRAM (Static Random Access Memory), a ROM (Read-Only Memory), an EEPROM (Electrically Erasable Programmable Read-Only Memory), a PROM (Programmable Read-Only Memory), a magnetic memory, a magnetic disk, and an optical disk, but is not limited thereto.
[0266] In one embodiment, the memory (1320) may store data or information identified, acquired, generated, or determined by the network entity (1300). The memory (1320) may store data or information identified, acquired, generated, or determined by the network entity (1300) in a compressed form.
[0267] Some modules that perform at least one operation of the network entity (1300) may be implemented as hardware modules, software modules, and / or a combination thereof. The memory (1320) may include software modules that perform at least some of the operations of the network entity (1300) described above. In one embodiment of the present disclosure, the modules included in the memory (1320) may perform operations by being executed by the processor (1310). For example, the modules (i.e., software modules) included in the memory (1320) may include programs, models, or algorithms that are executed according to the control or instructions of the processor (1310) and are configured to perform operations that derive output data for input data. Some modules that perform at least one operation of the network entity (1300) may be composed of multiple sub-modules or may constitute a single module.
[0268] The network entity (1300) may include more components than those illustrated in FIG. 13. In one embodiment of the present disclosure, the network entity (1300) may further include a communication interface (or communication module) for communicating with an external device. In one embodiment of the present disclosure, the network entity (1300) may further include an input / output device and / or an input / output interface.
[0269] It should be understood that the blocks and combinations of flowcharts presented in each of the present disclosure can be implemented by one or more computer programs containing computer-executable instructions. The one or more computer programs may be stored entirely in a single memory, or may be divided and stored across multiple different memories.
[0270] According to one embodiment of the present disclosure, a security-enhanced network slice can be provided in a next-generation communication system. For example, according to some embodiments of the present disclosure, a method for preventing inter-slice security threats when a UE uses multiple network slices simultaneously and a method for creating network slices to prevent new security threats due to quantum computing can be provided. Accordingly, a security-enhanced network slice can be provided to provide various security services required when utilizing network slices.
[0271] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the term "non-transitory storage medium" simply means a tangible device that does not contain signals (e.g., electromagnetic waves). This term does not distinguish between cases where data is permanently stored in the storage medium and cases where data is temporarily stored. For example, a "non-transitory storage medium" may include a buffer in which data is temporarily stored.
[0272] According to one embodiment, the method according to various embodiments disclosed in the present document may be provided as a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product (e.g., a downloadable app) may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.
[0273] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.
Claims
A method performed by a first network entity, A step of receiving a service profile associated with requirements for a network slice; A step of deriving a slice subnet profile associated with requirements for a network slice subnet of a specific domain based on the above service profile; and comprising the step of transmitting the slice subnet profile to a second network entity of the specific domain; A method according to claim 1, wherein the service profile comprises at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm; a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled; or a third attribute indicating the trustworthiness of one or more nodes within the network slice. In the first paragraph, The above service profile is: A method further comprising at least one of an attribute indicating a type of encryption algorithm to be applied to the network slice, an attribute indicating a type of authentication algorithm to be applied to the network slice, an attribute indicating a type of integrity check algorithm to be applied to the network slice, an attribute indicating a lifetime of an encryption key for the network slice, an identifier indicating a type of New Radio Encryption Algorithm (NEA) to be applied to the network slice, or an identifier indicating a type of New Radio Integrity Algorithm (NIA) to be applied to the network slice. In the first paragraph, The above service profile is: A method further comprising at least one of an attribute indicating an indicator for evaluating the performance of a security feature activated for said network slice, an attribute indicating whether said network slice supports a feature for protecting privacy, or an attribute indicating whether said network slice provides resiliency. In the first paragraph, The above service profile is: A method further comprising at least one of an attribute indicating one or more reliable nodes among haul interfaces of a Radio Access Network (RAN), an attribute indicating one or more reliable entities within the RAN, or an attribute indicating one or more reliable entities within a core network. In the first paragraph, A method wherein the service profile further comprises an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security. In paragraph 5, A method wherein the service profile further comprises at least one of an attribute indicating properties for protecting the network slice by a Post Quantum Cryptography (PQC) algorithm or an attribute indicating properties for protecting the network slice by a Quantum Key Distribution (QKD) algorithm. In the first paragraph, The above specific domain is a RAN (Radio Access Network) domain, A method wherein the service profile further includes an attribute indicating whether the N3 interface between the specific domain and a User Plane Function (UPF) is protected. In paragraph 7, A method according to claim 1, wherein the service profile further comprises at least one of: an attribute indicating a function for encrypting communication over the N3 interface, an attribute indicating a function for authenticating communication over the N3 interface, or an attribute indicating a function for providing replay protection to the N3 interface. In the first paragraph, A method wherein the specific domain is at least one of a Radio Access Network (RAN), an Open RAN (O-RAN), or a core network. A method performed by a first network entity, A step of receiving a slice subnet profile associated with requirements of a network slice subnet for a domain including the first network entity; A step of deriving requirements associated with the network slice subnet based on the above slice subnet profile; and A step of requesting the creation of a network function that satisfies the derived requirements to a second network entity of a domain including the first network entity, A method according to claim 1, wherein the slice subnet profile comprises at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm; a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled; or a third attribute indicating the trustworthiness of network entities associated with the network slice. In Article 10, The above slice subnet profile is: A method further comprising at least one of an attribute indicating a type of encryption algorithm to be applied to the network slice, an attribute indicating a type of authentication algorithm to be applied to the network slice, an attribute indicating a type of integrity check algorithm to be applied to the network slice, an attribute indicating a lifetime of an encryption key to be applied to the network slice, an identifier indicating a type of New Radio Encryption Algorithm (NEA) to be applied to the network slice, or an identifier indicating a type of New Radio Integrity Algorithm (NIA) to be applied to the network slice. In Article 10, The above slice subnet profile is: A method further comprising at least one of an attribute indicating an indicator for evaluating the performance of a security feature activated for said network slice, an attribute indicating whether said network slice supports a feature for protecting privacy, or an attribute indicating whether said network slice provides resiliency. In Article 10, The above slice subnet profile is: A method further comprising at least one of an attribute indicating one or more reliable nodes among haul interfaces of a Radio Access Network (RAN), an attribute indicating one or more reliable entities within the RAN, or an attribute indicating one or more reliable entities within a core network. In Article 10, A method wherein the slice subnet profile further includes an attribute indicating whether the network slice is protected by a cryptographic algorithm for quantum security. As a network entity, at least one processor; and A memory coupled to the processor, comprising at least one instruction for storing the instruction, By having said at least one processor execute said at least one instruction stored in said memory, said network entity: Receive service profiles associated with requirements for a network slice, Based on the above service profile, derive a slice subnet profile associated with the requirements for a network slice subnet of a specific domain, and Transmitting the slice subnet profile to a second network entity of the specific domain; A network entity, wherein the service profile comprises at least one of: a first attribute indicating whether the network slice is protected by a specific encryption algorithm, a second attribute indicating whether a requirement for monitoring the security performance of the network slice is enabled, or a third attribute indicating the trustworthiness of one or more nodes within the network slice.
Citation Information
Patent Citations
Apparatus and method for a unified slice manager
US11576020B1
Systems and methods for network based dynamic network slice selection control and federation
US20220369199A1