Enhanced Service Classification for Service Function Chaining in Next Generation Cellular Networks

Abstract

The present disclosure describes systems, methods, and devices related to service capability chaining classification in wireless networks. A communication network system may include a first cellular network device configured to receive Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data having an SDAP header; identify a Service Chaining Function (SFC) service identifier in the SDAP header; determine that the SFC service identifier is indicative of an SFC service profile, the SFC service profile indicative of a Quality of Service (QoS) traffic characteristic; identify an SFC traffic flow associated with the SFC service identifier; and transmit the SDAP data to a second cellular network device; where the second cellular network device is configured to receive the SDAP data from the first cellular network device; and transmit the SDAP data to a service capability of the system.

Description

[Technical field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Provisional Application No. 63 / 194,698, filed May 28, 2021, the disclosure of which is incorporated by reference as if set forth in its entirety.

[0002] The present disclosure relates generally to systems and methods for wireless communication, and more particularly to service capability chaining classification in sixth generation (6G) communication. [Background technology]

[0003] Wireless devices are becoming more and more prevalent and are increasingly using wireless channels. The 3rd Generation Partnership Program (3GPP®) is developing one or more standards for wireless communication. [Brief description of the drawings]

[0004] [Figure 1A] FIG. 1 illustrates an example service function chaining (SFC) traffic path for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0005] [Figure 1B] FIG. 2 illustrates an example SFC traffic path for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0006] [Diagram 2] FIG. 1 illustrates an example sixth-generation (6G) system architecture for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0007] [Diagram 3] FIG. 1 illustrates an exemplary SFC framework, in accordance with one or more exemplary embodiments of the present disclosure.

[0008] [Figure 4] FIG. 1 illustrates an example Service Data Adaptation Protocol (SDAP) data unit for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0009] [Figure 5A] FIG. 1 illustrates an example SFC service classification, in which an SFC service identifier identifies an SFC traffic path, in accordance with one or more example embodiments of the present disclosure.

[0010] [Figure 5B] FIG. 1 illustrates an example SFC service classification in which an SFC service identifier identifies an SFC traffic path using quality of service, in accordance with one or more example embodiments of the present disclosure.

[0011] [Figure 5C] 1 illustrates an example SFC service classification in which an SFC service identifier identifies an SFC traffic path and another identifier identifies a quality of service, in accordance with one or more example embodiments of the present disclosure.

[0012] [Figure 6] FIG. 1 illustrates a process for configuring an SFC service classifier in accordance with one or more exemplary embodiments of the present disclosure.

[0013] [Figure 7] FIG. 1 is a flow diagram of an example process for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0014] [Figure 8] FIG. 1 illustrates a network in accordance with one or more exemplary embodiments of the present disclosure.

[0015] [Figure 9] 1 is a schematic diagram of a wireless network in accordance with one or more exemplary embodiments of the present disclosure.

[0016] [Figure 10] FIG. 1 is a block diagram illustrating components in accordance with one or more exemplary embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] The following description and drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, algorithmic, and other changes. Portions and features of some embodiments may be included in, or substituted for, portions and features of other embodiments. The embodiments set forth in the claims include all available equivalents of those claims.

[0018] Wireless devices may communicate as defined by industry standards. For cellular telecommunications, standardization bodies such as the 3rd Generation Partnership Program (3GPP®) and the Open Radio Access Network (O-RAN) Alliance are defining communication techniques, including for sixth-generation (6G) cellular devices and service function chaining in cellular networks.

[0019] One 6G trend is the integration of information technology (IT) and communication technology (CT) with deeper penetration of cloud native paradigms, such as virtualization, programmability, automation, and microservices, into telecommunication networks. 6G networks are expected to transform most applications to microservice-based with enhanced architectures for computing, data, and communication planes to provide end-to-end services. This allows for flexible on-boarding and off-boarding of service functions, such as application instances, computing tasks, data pre-processing, and storage. Service function chaining (SFC) capability is required to realize different service logics along the traffic path. SFC refers to steering traffic using a sequence of virtualized / containerized network functions (VNFs / CNFs - virtual machines or containers that host virtualized / containerized network services).

[0020] SFC enables the creation of composite (e.g., network) services consisting of an ordered set of Service Functions (SFs) to be applied to packets and / or frames and / or flows selected as a result of classification. The purpose of classification is to distinguish different packets / flows based on rules from different layers such as Internet Protocol (IP) 5-tuple, packet / flow identifier, application, quality of service (QoS), etc., or for purposes such as load balancing. After traffic classification, encapsulation or transport mapping rules can be applied, for example, to steer SFC flows to traffic forwarders and SFC paths with required SFs.

[0021] In next generation cellular networks, SFC services can consist of Computing (Comp) / Data Service Functions (SFs), such as data labeling and pre-processing functions, or application instances as computing workloads. Current 5G networks handle non-SFC flows based on a QoS framework to set up in a Protocol Data Unit (PDU) session (i.e., end-to-end tunnel) between a user equipment device (UE) and a PDU session anchor UPF with DRB mapping in the gNB. The gNB performs DRB-to-TEID mapping based on the SDAP entity configuration and PDU session information set up by the RRC Reconfiguration message and PDU session establishment / modification procedures.

[0022] In addition, current 5G networks allow multiple QoS flows per PDU session, and a header (e.g., a Service Data Adaptation Protocol header of a Service Data Adaptation Protocol data unit) indicates which flow a packet belongs to. There is a 1:1 mapping between SDAP and PDU sessions, which may contain multiple QoS flows. A gNB may receive an SDAP entity (e.g., an SDAP PDU) and use the information in the SDAP entity header to determine which QoS flow and PDU session the entity belongs to. However, 5G networks do not currently classify flows in a way that distinguishes between SFC and non-SFC flows.

[0023] To enable SFC in next generation cellular networks, traffic or service classification is required to distinguish between SFC and non-SFC flows and apply corresponding mapping rules for transport and / or encapsulation, which can be based on various protocols such as segment routing (SR) in addition to GTP tunneling.

[0024] In one or more embodiments, the following solutions are provided in this disclosure to enable traffic / service classification: (1) a method for modeling SFC traffic; (2) defining essential information identified to describe SFC traffic; (3) defining information and mechanisms required to distinguish SFC flows from non-SFC flows; (4) defining information and mechanisms required to map SFC flows to transport and / or encapsulation; and (5) defining how to configure the above-mentioned information through control and user planes in cellular networks. In contrast, some existing SFC frameworks focus on service layer encapsulation rather than traffic classification. With regard to traffic classification in cellular networks, there are many more factors to consider, e.g., description of SFC flows, flow distinction from non-SFC flows, QoS, transport mapping, etc., that are not discussed in existing techniques.

[0025] In one or more embodiments, an SFC service classifier is proposed for the purpose of traffic classification based on the following scenarios: Scenario 1): A traffic classifier at the xNB or Scenario 2): A traffic classifier at the Comm SF / eUPF maps flows to the next-hop Comm SF / eUPF (e.g., traffic forwarder) with configured transport / encapsulation according to the SFC traffic path to distinguish SFC and non-SFC flows. An SFC service ID and corresponding SDAP extension are proposed to describe the SFC service profile and facilitate the xNB to map SFC flows based on different granularity in one scenario. An eUPF extension to set up a traffic classifier as an amendment to the 5G ULCL is proposed for another scenario. In this way, the 6G architecture enables SFC for computing / data service functions. This scenario requires computing and storage infrastructure for the cellular network.

[0026] In one or more embodiments, a 6G architecture that enables SFC is defined with detailed functional descriptions and procedures for setting up SFC paths. The service classifier may be in the RAN. However, the service classifier could also be in the Comm SF or UPF based on various mechanisms. In this disclosure, SFs are generally Comp / Data functions, including those commonly used in cloud and cellular environments, such as firewall, NAT, DPI, LI functions, etc. The 6G architecture adds AMF, SOEF, data plane CF and SF, comp plane CF and SF, Comm CF and SF, SOCF, enhanced UPF, enhanced SMF, and traffic classifier to the existing 5G architecture.

[0027] In one or more embodiments, SFC traffic may be modeled as a flow with QoS differentiation or default QoS similar to 5G QoS flows. As part of the SFC service context, a service ID may be used to identify the SFC flow or SFC traffic path. An SFC traffic path is defined as a combination of an ordered list of transports and SFs in the path. Note that differentiated QoS at the transport and SF levels is not included in the traffic path, which means that SFC flows using the same SFC traffic path may have different QoS at the transport and SF levels.

[0028] In one or more embodiments, essential functions in the SFC path include a traffic classifier and a traffic forwarder towards the SF. The SFC traffic path can be categorized into two scenarios based on the service classifier at the xNB and at one or more of the Comm SF / eUPF. When the Comm SF connects to the eUPF, a mechanism for interworking is required. The traffic path may include a Comm SF or an anchor UPF to connect to the DN, or the traffic path may terminate at the SF. In this disclosure, one extension is the service classifier. The traffic forwarder may be part of the Comm SF / eUPF function.

[0029] In one or more embodiments, the service classifier may be in the xNB for both Comm SF or eUPF based transport. There may be one or more Comm SF / eUPF to form the SFC path. For each Comm SF or eUPF, there may be one or more SFs depending on the mechanism enabling SFC or specific to the implementation scheme. The Comm SF / eUPF on the SFC path may act like an SFF and thus deliver packets to the local Comp / Data function.

[0030] In one or more embodiments, the SFC service profile is defined similarly to a QoS profile in current 5G networks, which is identified by an SFC service ID similar to a QFI / 5QI. Specifically, the SFC service profile may be the same as or part of an SFC service context.

[0031] In one or more embodiments, there is an option that allows the SDAP UL header to include an SFC Service ID, which can be used for service classification, transport mapping and encapsulation at the xNB.

[0032] In one or more embodiments, option 1 for updated fields in the UL SDAP header may include: (1) SFCI: A 1-bit indicator set to 1 to replace the R field, which is reserved and always set to 0. When SFCI is set to 1, the following field is the SFC Service ID, not the QFI. (2) SFC Service ID: The SFC identifier for the SFC profile that can be used with or without a PDU session. The length of the SFC Service ID may be different from the QFI / 5QI.

[0033] In one or more embodiments, option 2 for the updated fields of the UL SDAP header may include: (1) SFCI: a 1-bit indicator set to 1 to replace the R field, which is reserved and always set to 0, similar to SDAP option 1. (2) SFC Service ID: an SFC identifier for the SFC profile, similar to SDAP option 1. (3) M / I: a 1-bit SFC metadata indicator. If M / I is set to 1, there is metadata included in the SDAP header. (4) R: a 1-bit reserved and generally set to 0. (5) FI / 6G QoS Indicator: a QoS indicator for the SFC traffic characteristics, similar to the current QFI / 5QI. The QFI / 6G QoS indicator may be part of the SFC service profile. (6) Metadata Length: the number of bits or bytes of the SFC metadata. (7) Metadata: Metadata is SFC information including, but not limited to, information for service classification at the xNB, metadata to the SF for the SFC traffic path, updates for SFC parameters / policies, application-related information, and / or UE-related information. This metadata may be a container that is sent periodically between the UE and the xNB or may be triggered by an event, for example from an application.

[0034] In one or more embodiments, the DL SDAP header modification is similar to the UL and is transmitted from the xNB to the UE.

[0035] In one or more embodiments, the classification may be SFC service ID-based service classification at the xNB. This section provides a solution of mapping rules for SFC flows to SFC traffic paths. Solution 1.1: SFC flows share the same PDU session with non-SFC flows. In this solution, SFC flows share the same PDU session anchor (PSA) and session ID with other non-SFC flows. SFC service ID: Similar to QFI / 5QI, it refers to an SFC service profile that can be used for various PDU sessions. SFC service ID can be considered as an extension of QFI / 5QI. Service ID and partial / full SFC service context can be sent to the UE via the procedure to set up SFC flows. SDAP configuration: An SDAP entity is configured for each PDU session that includes both SFC and non-SFC flows. SDAP option 1. One scenario is when transport QoS information, such as traffic characteristics, priority, delay budget, GBR / non-GBR, etc., can be included in the SFC service profile. The SDAP entity is further configured according to the RRCReconfiguration message using the following modified ASN.1 description of SDAP-Config to add SFC flows as shown below.

[0036] SDAP-Config : : Sequence { pdu-Session PDU-SessionID sdap-HeaderDL ENUMERATED {present, absent}, sdap-HeaderUL ENUMERATED {present, absent}, defaultDRB BOOLEAN, mappedQoS-FlowsToAdd SEQUENCE (SIZE (1..MAXnROFQFIs)) OF QFI mappedQoS-FlowsToRelease SEQUENCE (SIZE (1..MAXnROFQFIs)) OF QFI mappedSFC-FlowsToAdd SEQUENCE (SIZE (1..MAXnROFServiceIDs)) OF Service ID mappedSFC-FlowsToRelease SEQUENCE (SIZE (1..MAXnROFServiceIDs)) OF Service ID The mappedSFC-FlowsToAdd SEQUENCE(SIZE(1..MAXnROFServiceIDs)) OF Service IDs and the mappedSFC-FlowsToRelease SEQUENCE(SIZE(1..MAXnROFServiceIDs)) OF Service IDs may be added to an existing configuration.

[0037] In one or more embodiments, the service classifier mapping rules may define that: for UL SFC traffic, the SDAP entity associated with the PDU session may be mapped to the DRB, and the reverse process is followed to map back to the PDU session, and then the SFC flow may be mapped to the N3' transport towards the next hop eUPF / Comm SF based on various traffic forwarder schemes, e.g., GTP tunnel, L3VPN tunnel, Segment Routing (SR) label, etc., identified by TEID. For DL ​​traffic, the PSA may apply packet filters to classify packets towards the next hop eUPF / Comm SF as N3' transport. The xNB follows the reverse process to map the TEID, other tunnel ID, SR label to the PDU session ID and thus the SDAP entity. The transport information at the eUPF / Comm SF is configured during the SFC flow setup procedure.

[0038] In one or more embodiments, for QoS: The Service ID can be carried with the transport protocol or as part of a new encapsulation / label that points to the traffic QoS characteristics as part of the SFC service profile and configured through the user plane. Thus, QoS can be achieved similarly to the current 5G QoS framework.

[0039] In one or more embodiments, solution 1.2 for having SFC classification at the xNB may be to use separate PDU sessions for SFC and non-SFC flows (e.g., in contrast to solution 1.1, where SFC flows may share a PDU session with non-SFC flows). In solution 1.2, separate PDU sessions may be set up for SFC flows. Thus, PDU sessions may be categorized as either PDU sessions for non-SFC flows or PDU sessions for SFC flows. Adding new SFC flows may be based on SFC PDU session establishment / modification procedures. Based on how the SFC service IDs are mapped at the xNB, there are three options that achieve different SFC flow granularity:

[0040] In one or more embodiments, option 1 for solution 1.2 may be as follows: The SFC Service ID may identify the SFC traffic path using the default traffic path QoS. In this option, the SFC Service ID is the same as the PDU Session ID for SFC, and additional SF level QoS may be handled at the application layer, for example through metadata or application level information. The PDU Session ID for SFC may be reused as the SFC Service ID as long as the SFC traffic path is the same. For this option, the SDAP header is not modified, but the SDAP entity configuration is updated to include the PDU-sessionType as SFC or non-SFC, as shown below.

[0041] SDAP-Config : : Sequence { pdu-Session PDU-SessionID pdu-SessionType ENUMERATED {SFC, non-SFC} sdap-HeaderDL ENUMERATED {present, absent}, sdap-HeaderUL ENUMERATED {present, absent}, defaultDRB BOOLEAN, mappedQoS-FlowsToAdd SEQUENCE (SIZE (1..MAXnROFQFIs)) OF QFI The mappedQoS-FlowsToRelease SEQUENCE (SIZE (1..MAXnROFQFIs)) OF QFIpdu-Session PDU-SessionID may be an update to the SDAP entity configuration.

[0042] In one or more embodiments, option 2 for solution 1.2 may be as follows: The SFC Service ID can identify the path with the QoS profile, and the mapping rules and extensions to the SDAP header are similar to solution 1.1.

[0043] In one or more embodiments, option 3 for solution 1.2 may be as follows: SFC Service ID identifies the path with the SFC Service ID, and additional QFI or 6G QoS identifier may be used for different QoS profiles. SDAP header modification option 2 may apply. For this option, SFC flows using different QFI / 6G QoS IDs may share the same Service ID and SDAP entity. The mapping rules are similar to solution 1.1.

[0044] In one or more embodiments, solution 2 may not include a PDU session for the SFC flow. The difference between solution 1.2 and solution 2 is that an SFC flow without a PDU session does not require a PSA. Therefore, mobility may be handled in a different way that is outside the scope of this disclosure. Solution 1.2 still applies and the SFC service ID may be used to identify the SDAP entity.

[0045] In one or more embodiments, the service classification may be a packet filter-based service classification at the xNB. Also, the service classification at the xNB may be based on a packet filter similar to ULCL or UPF. In this case, an additional function of a packet filter needs to be added to the xNB to filter the PDU, and there may be no impact on other layers such as SDAP on the UE and xNB sides.

[0046] In one or more embodiments, scenario 2 may include a service classifier in a Comm SF / eUPF. The service classifier may be in one or more Comm SFs / eUPFs. Specifically, the SFC path includes only an eUPF that represents a solution for 5G evolution that enables SFC. A user plane path may be set up. In general, the first Comm SF / eUPF may be configured as the service classifier.

[0047] In one or more embodiments, the present disclosure may provide a ULCL extension for a service classifier in eUPF. The eUPF may filter SFC packets based on a packet filter for the purpose of DL traffic classification (as a PSA) or UL multihoming. In this case, after applying the required packet filter, the eUPF may not only steer the SFC traffic based on the SFC path, but also apply related encapsulation / modification to the packets. The configuration of the SFC service classifier is shown as a modification of the existing ULCL setup procedure. The UE requests to set up an SFC service according to the message flow. Based on the SFC service context, including the UE subscription, network slice, application type, etc., the SOCF / SMF decides to set up an SFC service classifier in eUPF. The SMF may perform eUPF selection based on the requirements of the SFC service and the capabilities of the eUPF. The SMF establishes SFC service classifier rules in the selected eUPF, including packet filter information for the service classifier, mapped traffic forwarding rules based on the service classification, and / or modifications to the SFC packets, such as encapsulation or modifications to the packet header. The SMF updates the RANs such as the xNBs about the eUPF (SFC Service Classifier) ​​information so that the xNBs may apply traffic forwarding rules such as DRB-to-TEID mapping.

[0048] The above description is for purposes of illustration and is not intended to be limiting. Many other examples, configurations, processes, algorithms, etc. may exist, some of which are described in more detail below. Exemplary embodiments will now be described with reference to the accompanying figures.

[0049] FIG. 1A illustrates an example service function chaining (SFC) traffic path 100 for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0050] 1A and 1B, a UE device 102 may communicate (e.g., send PDUs) for both Comm SF or eUPF transport (e.g., Comm SF1 / eUPF1, Comm SF2 / eUPF2, ..., Comm SF N / eUPF N) to an xNB 104, which may have a service classifier 106 (e.g., indicating whether the PDU is SFC or non-SFC). There may be one or more Comm SFs / eUPFs to form an SFC traffic path. For each Comm SF or eUPF, there may be one or more SFs (e.g., SF 110 for Comm SF1 / eUPF1, SF 114 for Comm SF2 / eUPF2, SF 118 for Comm SF N / eUPF N), depending on, for example, the mechanism enabling SFC. The traffic path may include a Comm SF or an anchor UPF (eg, UPF / Comm SF 120) for connecting to the DN 122, or the traffic path may terminate in an SF.

[0051] In one or more embodiments, an SFC traffic path is defined as a combination of an ordered list of transports and SFs in the path. Distinguished QoS at the transport and SF levels is not included in the traffic path, meaning that SFC flows using the same SFC traffic path may have different QoS at the transport and SF levels. Functions in the SFC path include a traffic classifier and a traffic forwarder for the SFs. The SFC traffic path may be categorized into two scenarios based on the service classifiers at the xNB 104 and at one or more of the Comm SFs / eUPFs.

[0052] FIG. 1B illustrates an example SFC traffic path 150 for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0053] Referring to FIG. 1B, the Comm SF / eUPF may have a service classifier (e.g., Comm SF1 / eUPF1 may have a service classifier 152, Comm SF2 / eUPF2 may have a service classifier 154, and Comm SF N / eUPF N may have a service classifier 156). Specifically, the SFC path includes only an eUPF that represents a solution for 5G evolution that enables SFC. The user plane path may be set up according to the procedure. Generally, the first Comm SF / eUPF may be configured as a service classifier.

[0054] FIG. 2 illustrates an example sixth-generation (6G) system architecture 200 for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0055] Referring to FIG. 2, the 6G system architecture 200 extends PCF 202, AMF 204 (e.g., from the existing 5G system architecture as shown in FIG. 8), adds SOEF 206, data plane CF 208, comp. plane CF 210, comm. CF 212, SOCF 214 (to the existing 5G system architecture as shown in FIG. 8), extends SMF 216 (e.g., from the existing 5G system architecture as shown in FIG. 8), adds traffic classifier 218 to RAN 219, adds DSF 220, adds comp. SF 222, adds comm. SF 224, adds UPF 226, and adds UPF 228.

[0056] With further reference to FIG. 2, the 6G system architecture 200 includes the NSSF 230, the NEF 232, the NRF 234, the UDM 236, the AF 238, the AUSF 240, the UE 242, the DN 244, and the DN 246 from the 5G architecture (e.g., shown in FIG. 8).

[0057] In one or more embodiments, the functionality of the comm. CF 212 includes, but is not limited to, communication service management to SFC or non-SFC services to other NFs via the Nccf, selection and control of a comm. SF to set up SFC or non-SFC communication services (e.g., selecting a comm. SF 224 based on capabilities, location for mobility), configuration of one or more comm. SFs via N4′ for: (1) supported transport / networking protocols of different layers, (2) matching rules for traffic flows, e.g., based on criteria such as protocols, metadata, physical or virtual port IDs, packet filters such as IP5 tuples, Ethernet addresses, vLAN tags, etc., (3) routing information for traffic flows based on traffic matching rules, and (4) actions taken for traffic flows based on traffic matching rules. The functionality of the comm. CF 212 may also include life cycle management of the comm. SFs, i.e., onboarding, offboarding or migration, and billing data collection for communication services.

[0058] In one or more embodiments, the functions of the comm. SF224 include, but are not limited to, communication services such as packet routing and forwarding on the user plane based on different protocols and traffic rules; adding, modifying, or removing packet labels based on configuration from the comm. CF212; applying traffic rules such as traffic matching rules and performing actions required based on configuration from the comm. CF; an anchor point to handle the mobility of the UE242 to complement the UPF226; and traffic monitoring and reporting to the comm. CF212.

[0059] In one or more embodiments, the functionality of SOCF 214 includes, but is not limited to, providing service orchestration and chaining services such as SFC establishment, modification and release to NFs or to UEs via NSOCFs, generating comp. / comm. / data plane configurations and requests based on service orchestration requirements, and generating charging records based on transactions for SFCs.

[0060] In one or more embodiments, the functionality of the SOEF 206 includes, but is not limited to, exposing service orchestration and chaining capabilities to third parties such as the AF, supporting service discovery for service orchestration and chaining to the AF, processing service orchestration and chaining requests based on configured policies of the cellular network, generating service requirements to the SOCF 214 to request orchestration and chaining services from the AF, and exposing an interface to the AF to manage firmware and profiles used by the NFs and NF software / hardware. For example, vendors may provide hardware platform / accelerator technology to improve performance, such as throughput and latency, of the UPF 226 or other NFs, and may include SFC support directly within the accelerator. The SOEF 206 may be an extension to the NEF 232 or a standalone function.

[0061] In one or more embodiments, the SFC service context may refer to information for defining an SFC service and associated requirements, and generally includes two aspects: SFC information and transport / networking information. The SFC context information is communicated to the relevant control plane functions, such as the SOCF 214, SMF 216, comp. / data / comm.CF 208, 210, 212, during the setup of the SFC logic. The control plane functions may then further configure the required user plane functions on the SFC path. The SFC information includes, but is not limited to, Service ID: identifying the SFC service; Application ID / Type such as APN / DNN; UE ID / UE Group ID; Network Slice ID; Access Type; PDU Session ID and related information such as PSA if the SFC service belongs to a PDU session; Traffic Type / Classification Rules; Security related information: keys, certificates; Service continuity mode; SFC Requirements: Required network chain for SF, such as comp. / data service information and its order; Computing capabilities and workload as described in the computing manifest, and associated metadata to describe data functions and storage, and required QoS such as QoS characteristics on traffic flows such as GBR, non-GBR, priority, maximum data rate, latency, etc., and additional requirements for service function processing, such as required computing resources, processing priority, delay, etc.; Required capabilities such as protocols for data description protocols; and Required location of Comp / data service functions.The transport / networking information includes, but is not limited to, typical SFC dynamic configuration information: network and interface information such as ethX, network CIDR, and network type: VLAN, etc.; transport / networking mapping / routing rules: extended UPF 226 to support GTP tunneling, required overlay / underlay such as segment routing (SR) as the transport / networking protocol; required communication model, e.g., load balancing, multipath, etc.; and required protocol and encapsulation options such as no service layer encapsulation, with service layer encapsulation, or with combined service layer and SR encapsulation.

[0062] In one or more embodiments, Nsocf_SFC (e.g., Create, Update, Release) are services provided to V / I-SOCF for roaming purposes, similar to Nsmf_PDUSession (e.g., Create, Update, Release) as described in clause 5.2.8.1 3GPP TS 23.502. Nsocf_SFC (e.g., CreateSFCContext, UpdateSFCContext, ReleaseSFCContext) are services provided to establish / update / release SFC context information to set up / modify / delete SFC flows. Other services are Subscribe / Notify, which publish SFC related information and events to NFs, such as SOEF 206, AMF 204, SMF 216, etc. SOCF 214 may be an extension function to existing NFs for 5G, such as SMF 216, or a standalone function.

[0063] FIG. 3 illustrates an example SFC framework 300 in accordance with one or more example embodiments of the present disclosure.

[0064] After traffic classification, encapsulation or transport mapping rules may be applied to steer SFC flows to traffic forwarders and SFC paths with required SFs, as shown in Figure 3 as one example. The purpose of SFC and non-SFC classification is to distinguish different packets / flows based on rules from different layers such as IP5 tuple, packet / flow identifier, application, QoS, etc., or for purposes such as load balancing.

[0065] In next-generation cellular networks, an SFC service may consist of a Comp / Data Service Function (SF), such as data labeling and pre-processing functions, or an application instance as a computing workload. Current 5G networks handle non-SFC flows based on a QoS framework to set up a PDU session (i.e., an end-to-end tunnel) between the UE and the PDU session anchor UPF with DRB mapping in the gNB.

[0066] The gNB performs DRB-to-TEID mapping based on the SDAP entity configuration and PDU session information set up by the RRCReconfiguration message and PDU Session Establishment / Modification procedure. A UL SDAP Data PDU with an SDAP header is shown in Figure 4.

[0067] FIG. 4 illustrates an example Service Data Adaptation Protocol (SDAP) data unit for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0068] 4, a UL SDAP Data PDU 400 is shown having an SDAP header, which may include a 1-bit D / C field 402 to indicate whether the SDAP is a control PDU, a 1-bit R field 404 with a reserved bit, and a multi-bit QFI field 406 to indicate a QoS flow using a QFI. The UL SDAP Data PDU 400 may include data 408 on one or more octets (e.g., octets 1 through N).

[0069] 4, the UL SDAP Data PDU 420 may indicate modifications to the UL SDAP Data PDU 400 by including an SFC Indicator (SFCI) 422 and an SFC Service ID 424. The SFCI 422 may be a one-bit indicator set to 1 to replace the R field 404, which is reserved and always set to 0. When the SFCI 422 is set to 1, the following field is the SFC Service ID 424 instead of the QFI field 406. The SFC Service ID 424 may be an SFC identifier for an SFC profile and may be used with or without a PDU session. The length of the SFC Service ID 424 may be different than the QFI / 5QI.

[0070] 4, UL SDAP data PDU 430 may represent modifications to UL SDAP data PDU 400 by including SFCI 422, SFC service ID 431 (e.g., similar to SFC service ID 424), M / I field 432 (e.g., a 1-bit SFC metadata indicator; if M / I field 432 is set to 1, there is metadata included in the SDAP header), R field 434 (e.g., 1 bit reserved and generally set to 0), QFI / 6G QoS indicator 436 (e.g., a QoS identifier for the SFC traffic characteristics, similar to the current QFI / 5QI; QFI / 6G QoS indicator 436 may be part of the SFC Service Profile), metadata length field 438 (e.g., number of bits or bytes of SFC metadata), metadata 440, and data 408.

[0071] In one or more embodiments, metadata 440 may represent SFC information including, but not limited to, information for service classification at the xNB, metadata to the SF for SFC traffic paths, updates for SFC parameters / policies, application related information, and UE related information. Metadata 440 may be a container that is sent between the UE and the xNB periodically or triggered by an event, for example from an application.

[0072] In one or more embodiments, not shown, the DL SDAP header modification is similar to the UL and is transmitted from the xNB to the UE.

[0073] FIG. 5A illustrates an example SFC service classification 500 in which an SFC service identifier identifies an SFC traffic path, in accordance with one or more example embodiments of the present disclosure.

[0074] 5A, the SFC service identifier identifies the SFC traffic path with the default traffic path QoS. The UE 502 may use the SFC traffic path 504 to communicate with the xNB 506 having the classifier, which may use the SFC traffic path 508 to communicate with the comm SF / eUPF 510 (and potentially other comm SF / eUPFs as shown in FIGS. 1A and 1B), which may communicate with their respective SFs (e.g., SF 512).

[0075] In this option, the SFC Service ID is the same as the PDU Session ID for SFC, and additional SF-level QoS can be handled at the application layer, for example through metadata or application level information. The PDU Session ID for SFC may be reused as the SFC Service ID as long as the SFC traffic path is the same. For this option, the SDAP header is not modified, but the SDAP entity configuration is updated to include the PDU-sessionType as SFC or non-SFC.

[0076] FIG. 5B illustrates an example SFC service classification 520 in which an SFC service identifier uses quality of service to identify SFC traffic paths in accordance with one or more example embodiments of the present disclosure.

[0077] In Figure 5B, the SFC service ID may identify the SFC traffic path, and additional QFI or 6G QoS identifiers may be used for different QoS profiles. The UE 502 may use multiple SFC paths (e.g., SFC path 522, SFC path 524) to communicate with the xNB 506, which may use multiple SFC paths (e.g., SFC path 526 with serviceID1, SFC path 528 with serviceID2) to communicate with the comm SF / eUPF 510 and SF 512. In this option, the UL SDAP data PDU 430 of Figure 4 may be used, and SFC flows with different QFI / 6G QoS IDs can share the same service ID and SDAP entity.

[0078] FIG. 5C illustrates an example SFC service classification 540 in which an SFC service identifier identifies an SFC traffic path and another identifier identifies a quality of service, in accordance with one or more example embodiments of the present disclosure.

[0079] In FIG. 5C, the SFC service ID may identify the path using the SFC service ID, and additional QFI or 6G QoS identifiers may be used for different QoS profiles. The UL SDAP data PDU 430 of FIG. 4 may be used. For this option, SFC flows using different QFI / 6G QoS IDs may share the same service ID and SDAP entity. The UE 502 may communicate with the xNB 506 using an SFC path 542 using multiple QFI options (e.g., QFI1, QFI2), which may communicate with the comm SF / eUPF 510 and SF 512 using an SFC path 544 having an SFC path using QFI1 and an SFC path using QFI2.

[0080] In one or more embodiments, the difference between the options in Figures 5A-5C and the alternative solution where no PDU session is used for the SFC flow is that the SFC flow without a PDU session does not require a PSA. Therefore, mobility may be handled differently. The options in Figures 5A-5C may still apply and the SFC service ID may be used to identify the SDAP entity.

[0081] FIG. 6 illustrates a process 600 for configuring an SFC service classifier in accordance with one or more exemplary embodiments of the present disclosure.

[0082] Referring to FIG. 6, the process 600 may include a UE 602, an xNB / AMF 604, a SOCF 606, an SMF 608, and an eUPF 610 having an SFC service classifier.

[0083] In step 612, the UE 602 requests to set up an SFC service according to the message flow. Based on the SFC service context, including the UE's subscription, network slice, application type, etc., the SOCF 606 and / or the SMF 608 decide to set up an SFC service classifier in the eUPF 610. The SMF 608 may perform eUPF selection based on the requirements of the SFC service and the capabilities of the eUPF 610.

[0084] In step 614, the SMF 608 establishes SFC service classifier rules in the selected eUPF, including packet filter information for the service classifier, mapped traffic forwarding rules based on the service classification, and / or modifications to the SFC packet, such as encapsulation or modifications to the packet header.

[0085] In step 616, the SMF 608 updates the RAN, e.g., the xNB, with the eUPF 610 (SFC service classifier) ​​information. The xNB may then apply traffic forwarding rules similar to the DRB-to-TEID mapping to forward the UL SFC traffic 618, and the eUPF 610 may perform SFC service classification 620 using the SFC service classifier.

[0086] FIG. 7 illustrates a flow diagram of an example process 700 for SFC service classification, in accordance with one or more example embodiments of the present disclosure.

[0087] At block 702, a device (or system, e.g., a Node B device such as xNB 104 of FIGS. 1A and 1B) may receive SDAP data (e.g., using one of the formats shown in FIG. 4) from a UE (e.g., UE 102 of FIGS. 1A and 1B).

[0088] In block 704, the device may identify an SFC service identifier (eg, SFC service ID 424 or SFC service ID 431 of FIG. 4) in the SFC data. The SFC service identifier may distinguish the SFC data from non-SFC data (eg, SFC classification).

[0089] At block 706, the device may determine that an SFC service identifier in the SDAP data indicates an SFC service profile. The SFC service profile may indicate QoS traffic characteristics used to control transmission of the SDAP data.

[0090] At block 708, the device may identify an SFC traffic flow indicated by the SFC service identifier and used to transport the SDAP data.

[0091] At block 710, the device may send the SDAP data to a device (e.g., a communications service function such as the Comm SF / UPF of FIGS. 1A and 1B, or a UPF such as UPF 120 of FIGS. 1A and 1B). The device may receive the SDAP data or may send the SDAP data to a service function (e.g., SF 114 and SF 118 of FIGS. 1A and 1B).

[0092] It should be understood that the above description is intended to be illustrative and not limiting.

[0093] FIG. 8 illustrates a network 800 in accordance with one or more example embodiments of the present disclosure.

[0094] 2 may join and extend network 800. In this manner, the components of 6G system architecture 200 also shown in FIG. 8 may correspond to the functionality described below with respect to FIG. 8 and the additional extension functions described above with respect to FIG. 2.

[0095] Network 800 may operate in a manner consistent with 3GPP® technical specifications for LTE or 5G / NR systems, however, the example embodiments are not limited in this respect and the described embodiments may be applied to other networks that would benefit from the principles described herein, such as, for example, future 3GPP® systems (e.g., 5G systems), etc.

[0096] The network 800 may include a UE 802, which may include any mobile or non-mobile computing device designed to communicate with the RAN 804 via an over-the-air connection. The UE 802 may be communicatively coupled to the RAN 804 by a Uu interface. The UE 802 may be, but is not limited to, a smartphone, a tablet computer, a wearable computing device, a desktop computer, a laptop computer, an in-vehicle infotainment, an in-vehicle entertainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a dash-top mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a network appliance, a machine type communication device, an M2M or D2D device, an IoT device, and the like.

[0097] In some embodiments, the network 800 may include multiple UEs directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

[0098] In some embodiments, the UE 802 may further communicate with the AP 806 via an over-the-air connection. The AP 806 may manage a WLAN connection that may function to offload some / all of the network traffic from the RAN 804. The connection between the UE 802 and the AP 806 may be consistent with any IEEE 802.11 protocol, where the AP 806 may be a wireless fidelity (Wi-Fi) router. In some embodiments, the UE 802, RAN 804, and AP 806 may utilize cellular WLAN aggregation (e.g., LWA / LWIP). Cellular WLAN aggregation may include the UE 802 being configured by the RAN 804 to utilize both cellular radio resources and WLAN resources.

[0099] The RAN 804 may include one or more access nodes, e.g., AN 808. The AN 808 may terminate the air interface protocols of the UE 802 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and L1 protocols. In this manner, the AN 808 may enable data / voice connectivity between the CN 820 and the UE 802. In some embodiments, the AN 808 may be implemented in a discrete device or as one or more software entities running on a server computer as part of a virtual network, which may be referred to as, for example, a CRAN or a virtual baseband unit pool. The AN 808 may be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 808 may be a macrocell base station, or a low-power base station for providing a femtocell, picocell, or other similar cell having a smaller coverage area, smaller user capacity, or higher bandwidth compared to a macrocell.

[0100] In embodiments where the RAN 804 includes multiple ANs, they may be coupled to each other via an X2 interface (if the RAN 804 is an LTE RAN) or an Xn interface (if the RAN 804 is a 5G RAN). The X2 / Xn interface, which in some embodiments may be separated into a control / user plane interface, may allow the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, and the like.

[0101] Each of the ANs of the RAN 804 may manage one or more cells, cell groups, component carriers, etc., to provide the UE 802 with an air interface for network access. The UE 802 may be simultaneously connected to multiple cells provided by the same or different ANs of the RAN 804. For example, the UE 802 and the RAN 804 may use carrier aggregation to enable the UE 802 to connect to multiple component carriers, each corresponding to a Pcell or an Scell. In a dual connectivity scenario, the first AN may be a master node providing an MCG, and the second AN may be a secondary node providing an SCG. The first / second ANs may be any combination of eNBs, gNBs, ng-eNBs, etc.

[0102] The RAN 804 may provide an air interface over licensed or unlicensed spectrum. To operate in the unlicensed spectrum, the node may use LAA, eLAA, and / or feLAA mechanisms based on CA techniques using PCell / Scell. Before accessing the unlicensed spectrum, the node may perform medium / carrier sensing operations, for example based on a Listen-Before-Talk (LBT) protocol.

[0103] In a V2X scenario, the UE 802 or AN 808 may be or operate as an RSU, which may refer to any traffic infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable AN or a static (or relatively static) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU"; and so on. In one example, the RSU is a computing device coupled to a radio frequency circuit located at the roadside that provides connectivity support to passing vehicular UEs. The RSU may also include internal data storage circuitry that stores intersection map geometry, traffic statistics, media, and applications / software that sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communication required for high speed events, such as collision avoidance, traffic warnings, etc. Additionally or alternatively, the RSU may provide other cellular / WLAN communication services. The components of the RSU may be packaged in a weather-resistant enclosure suitable for outdoor installation and may include a traffic signal controller or a network interface controller for providing a wired connection (e.g., Ethernet) to a backhaul network.

[0104] In some embodiments, the RAN 804 may be an LTE RAN 810 including an eNB, such as an eNB 812. The LTE RAN 810 may provide an LTE air interface with the following characteristics: 15 kHz SCS; CP-OFDM waveform for DL ​​and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH / PDCCH DMRS for PDSCH / PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface may operate in sub-6 GHz bands.

[0105] In some embodiments, the RAN 804 may be an NG-RAN 814 having a gNB, e.g., gNB 816, or an ng-eNB, e.g., ng-eNB 818. The gNB 816 may connect to a 5G-capable UE using a 5G NR interface. The gNB 816 may connect to a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 818 may also connect to a 5G core through an NG interface, but may connect to a UE through an LTE air interface. The gNB 816 and the ng-eNB 818 may connect to each other through an Xn interface.

[0106] In some embodiments, the NG interface may be divided into two parts: an NG User Plane (NG-U) interface (e.g., N3 interface), which carries traffic data between the NG-RAN 814 nodes and the UPF 848, and an NG Control Plane (NG-C) interface (e.g., N2 interface), which is the signaling interface between the NG-RAN 814 nodes and the AMF 844.

[0107] The NG-RAN 814 may provide the 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH / PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS and may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate on the FR1 band, which includes sub-6 GHz bands, or on the FR2 band, which includes bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include SSB, which is an area of ​​the downlink resource grid that includes PSS / SSS / PBCH.

[0108] In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWPs may be used for dynamic adaptation of SCS. For example, the UE 802 may be configured with multiple BWPs, each BWP configuration having a different SCS. When a BWP change is indicated to the UE 802, the SCS of the transmission is also changed. Another use case example of BWPs relates to power saving. In particular, multiple BWPs may be configured to support data transmissions under various traffic load scenarios for the UE 802 using different amounts of frequency resources (e.g., PRBs). BWPs including a smaller number of PRBs may be used for data transmissions with small traffic loads while enabling power saving at the UE 802 and in some cases at the gNB 816. BWPs including a larger number of PRBs may be used for scenarios with higher traffic loads. The RAN 804 is communicatively coupled to the CN 820, which includes network elements that provide various functions to support data and telecommunication services to customers / subscribers (e.g., users of the UE 802). The components of CN 820 may be implemented within one physical node or separate physical nodes. In some embodiments, NFV may be leveraged to virtualize any or all of the functions provided by the network elements of CN 820 onto physical compute / storage resources in servers, switches, etc. A logical instantiation of CN 820 may be referred to as a network slice, and a logical instantiation of a portion of CN 820 may be referred to as a network sub-slice.

[0109] In some embodiments, the CN 820 may be an LTE CN 822, which may also be referred to as an EPC. The LTE CN 822 may include an MME 824, an SGW 826, an SGSN 828, an HSS 830, a PGW 832, and a PCRF 834 coupled together through interfaces (or "reference points") as shown. The functionality of the elements of the LTE CN 822 may be briefly introduced as follows.

[0110] The MME 824 may implement mobility management functions that track the current location of the UE 802 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc.

[0111] The SGW 826 may terminate the S1 interface towards the RAN and route data packets between the RAN and the LTE CN 822. The SGW 826 may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility. Other roles may include lawful interception, charging, and some policy enforcement.

[0112] The SGSN 828 may track the location of the UE 802 and perform security functions and access control. In addition, the SGSN 828 may perform EPC inter-node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by the MME 824; MME selection for handover; etc. An S3 reference point between the MME 824 and the SGSN 828 may enable exchange of user and bearer information for inter-3GPP access network mobility in idle / active state.

[0113] The HSS 830 may include a database for network users, including subscription-related information, to support handling of communication sessions by network entities. The HSS 830 may provide support for routing / roaming, authentication, authorization, name / address resolution, location dependency, etc. An S6a reference point between the HSS 830 and the MME 824 may enable transfer of subscription and authentication data to authenticate / authorize user access to the LTE CN 820.

[0114] The PGW 832 may terminate an SGi interface towards a data network (DN) 836, which may include an application / content server 838. The PGW 832 may route data packets between the LTE CN 822 and the data network 836. The PGW 832 may be coupled to the SGW 826 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 832 may further include a node for policy enforcement and charging data collection (e.g., PCEF). Furthermore, the SGi reference point between the PGW 832 and the data network 836 may be an operator external public, private PDN, or intra-operator packet data network, e.g., for provisioning of IMS services. The PGW 832 may be coupled to the PCRF 834 via a Gx reference point. The PCRF 834 is the policy and charging control element of the LTE CN 822. The PCRF 834 may be communicatively coupled to the app / content server 838 to determine appropriate QoS and charging parameters for the service flows. The PCRF 832 may provision the associated rules to the PCEF (via the Gx reference point) with the appropriate TFT and QCI.

[0115] In some embodiments, the CN 820 may be a 5GC 840. The 5GC 840 may include an AUSF 842, an AMF 844, an SMF 846, a UPF 848, an NSSF 850, an NEF 852, an NRF 854, a PCF 856, an UDM 858, an AF 860, and an LMF 862, coupled together through interfaces (or "reference points") as shown. The functionality of the elements of the 5GC 840 may be briefly introduced as follows: The AUSF 842 may store data for authentication of the UE 802 and handle authentication related functions. The AUSF 842 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 840 through reference points as shown, the AUSF 842 may exhibit a Nausf service based interface.

[0116] The AMF 844 may enable other functions of the 5GC 840 to communicate with the UE 802 and the RAN 804 and to subscribe to notifications about mobility events related to the UE 802. The AMF 844 may be responsible for registration management (e.g., for registering the UE 802), connection management, reachability management, mobility management, lawful interception of AMF related events, access authentication and authorization. The AMF 844 may provide transport for SM messages between the UE 802 and the SMF 846 and act as a transparent proxy for routing of SM messages. The AMF 844 may also provide transport for SMS messages between the UE 802 and the SMSF. The AMF 844 may interact with the AUSF 842 and the UE 802 to perform various security anchor and context management functions. Furthermore, the AMF 844 may be the termination point of the RAN CP interface, which may include or be the N2 reference point between the RAN 804 and the AMF 844; the AMF 844 is the termination point of the NAS (N1) signaling and may perform NAS ciphering and integrity protection. The AMF 844 may also support NAS signaling with the UE 802 over the N3 IWF interface.

[0117] The SMF 846 may be responsible for SM (e.g., session establishment, tunnel management between the UPF 848 and the AN 808); UE IP address allocation and management (including selective admission); selection and control of the UP function; configuring traffic steering in the UPF 848 to route traffic to the appropriate destination; termination of the interface towards the policy control function; controlling the policy enforcement, charging, and QoS portions; lawful interception (for SM events and the interface towards the LI system); termination of the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent through the N2 to the AN 808 via the AMF 844; and determining the SSC mode of the session. SM may refer to management of a PDU session, and a PDU session or "session" may refer to a PDU connection service that provides or enables the exchange of PDUs between the UE 802 and the data network 836.

[0118] The UPF 848 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to the data network 836, and a branching point to support multi-homed PDU sessions. The UPF 848 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic validation (e.g., SDF to QoS flow mapping), perform transport level packet marking in the uplink and downlink, and perform downlink packet buffering and triggering of downlink data notifications. The UPF 848 may include an uplink classifier to support routing traffic flows to the data network.

[0119] The NSSF 850 ​​may select a set of network slice instances to serve the UE 802. The NSSF 850 ​​may also determine the allowed NSSAI and, if necessary, the mapping to the subscribed S-NSSAI. The NSSF 850 ​​may also determine the AMF set to be used to serve the UE 802, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 854. The selection of the set of network slice instances for the UE 802 may be triggered by the AMF 844 with which the UE 802 is registered by interacting with the NSSF 850, which may result in a change of the AMF. The NSSF 850 ​​may interact with the AMF 844 via the N22 reference point; it may communicate with another NSSF in the visited network via the N31 reference point (not shown). Furthermore, the NSSF 850 ​​may exhibit an Nnssf service-based interface.

[0120] The NEF 852 may securely expose services and capabilities provided by 3GPP network functions for third parties, internal publication / re-publication, AFs (e.g., AFs 860), edge computing or fog computing systems, etc. In such an embodiment, the NEF 852 may authenticate, authorize, or throttle the AFs. The NEF 852 may also translate information exchanged with the AFs 860 and with internal network functions. For example, the NEF 852 may translate between AF service identifiers and internal 5GC information. The NEF 852 may also receive information from other NFs based on the published capabilities of the other NFs. This information may be stored in the NEF 852 as structured data or in a data storage NF using a standardized interface. The stored information can then be re-published by the NEF 852 to other NFs and AFs, or used for other purposes such as analysis. Additionally, the NEF 852 may present an NEF service-based interface. The NRF 854 may support service discovery functions, receive NF discovery requests from NF instances, and provide information of discovered NF instances to NF instances. The NRF 854 also maintains information of available NF instances and their supported services. As used herein, "instantiate," "instantiation," and similar terms may refer to the creation of an instance, and an "instance" may refer to a concrete occurrence of an object, such as may occur during the execution of program code. Additionally, the NRF 854 may expose an Nnrf service-based interface. The PCF 856 may provide policy rules to control plane functions for their enforcement, and may support a unified policy framework for governing network behavior. The PCF 856 may also implement a front end to access subscription information related to policy decisions within the UDRs of the UDM 858.In addition to communicating with functions through reference points as shown, the PCF 856 exhibits an Npcf service-based interface. The UDM 858 may process subscription related information to support processing of communication sessions by network entities and may store subscription data for the UE 802. For example, subscription data may be communicated through the N8 reference point between the UDM 858 and the AMF 844. The UDM 858 may include two parts: an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 858 and the PCF 856, and / or structured data for publishing and application data for the NEF 852 (including PFD for application discovery, application request information for multiple UEs 802). A Nudr service-based interface may be exhibited by the UDR 821 to enable the UDM 858, the PCF 856, and the NEF 852 to access a particular set of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of associated data changes in the UDR. The UDM may include a UDM-FE responsible for handling credentials, location management, subscription management, etc. Several different front-ends may provide services to the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credentials processing, user identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 858 may present a Nudm service-based interface. The AF 860 may provide application influence over traffic routing, provide access to the NEF, and interact with a policy framework for policy control.

[0121] In some embodiments, the 5GC 840 may enable edge computing by selecting an operator / third-party service to be geographically close to the point where the UE 802 is connected to the network. This may reduce latency and load on the network. To provide edge computing implementation, the 5GC 840 may select a UPF 848 close to the UE 802 and perform traffic steering from the UPF 848 to the data network 836 via the N6 interface. This may be based on UE subscription data, UE location, and information provided by the AF 860. In this way, the AF 860 may affect the UPF (re)selection and traffic routing. Based on the operator deployment, when the AF 860 is deemed to be a trusted entity, the network operator may allow the AF 860 to interact directly with the associated NFs. Furthermore, the AF 860 may represent a Naf service-based interface. The data network 836 may represent various network operator services, Internet access, or third-party services that may be provided by one or more servers, including, for example, the application / content server 838.

[0122] The LMF 862 may receive measurement information (e.g., measurement reports) from the NG-RAN 814 and / or the UE 802 via the AMF 844. The LMF 862 may use the measurement information to determine a device location for indoor and / or outdoor positioning.

[0123] FIG. 9 illustrates a schematic diagram of a wireless network 900 in accordance with one or more exemplary embodiments of the present disclosure.

[0124] The wireless network 900 may include a UE 902 in wireless communication with an AN 904. The UE 902 and the AN 904 may be similar to and substantially interchangeable with similarly named components described elsewhere herein. The UE 902 may be communicatively coupled to the AN 904 via a connection 906. The connection 906 is depicted as an air interface enabling the communicative coupling and may be consistent with a cellular communication protocol such as an LTE protocol or a 5G NR protocol operating in mmWave or sub-6 GHz frequencies. The UE 902 may include a host platform 908 coupled to a modem platform 910. The host platform 908 may include an application processing circuit 912 that may be coupled to a protocol processing circuit 914 of the modem platform 910. The application processing circuit 912 may execute various applications for the UE 902 to source / sink application data. The application processing circuit 912 may further implement one or more layer operations for transmitting / receiving application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations. The protocol processing circuitry 914 may implement one or more of the layer operations to facilitate transmission or reception of data over the connection 906. The layer operations implemented by the protocol processing circuitry 914 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations. Additionally, the modem platform 910 may include digital baseband circuitry 916 that may implement one or more layer operations "below" the layer operations performed by the protocol processing circuitry 914 in the network protocol stack.These operations may include PHY operations including, for example, one or more of HARQ-ACK functions, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, metric determination of received symbols / bits, multi-antenna port precoding / decoding (which may include one or more of space-time, space-frequency, or spatial coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions. Additionally, the modem platform 910 may include an RF front end (RFFE) 924, which may include or be connected to transmit circuitry 918, receive circuitry 920, RF circuitry 922, and one or more antenna panels 926. Briefly, the transmit circuitry 918 may include digital-to-analog converters, mixers, intermediate frequency (IF) components, etc.; the receive circuitry 920 may include analog-to-digital converters, mixers, IF components, etc.; the RF circuitry 922 may include low noise amplifiers, power amplifiers, power tracking components, etc.; the RFFE 924 may include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 918, receive circuitry 920, RF circuitry 922, RFFE 924, and antenna panel 926 (collectively referred to as the "transmit / receive components") may be specific to the details of a particular implementation, such as, for example, whether the communication is TDM or FDM, whether mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains, may be disposed in the same or different chips / modules, etc. In some embodiments, the protocol processing circuitry 914 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit / receive components.UE reception may be established by and through the antenna panel 926, RFFE 924, RF circuitry 922, receive circuitry 920, digital baseband circuitry 916, and protocol processing circuitry 914. In some embodiments, the antenna panel 926 may receive transmissions from the AN 904 by receive beamforming signals that are received by multiple antennas / antenna elements of one or more of the antenna panels 926.

[0125] UE transmissions may be established by and through protocol processing circuitry 914, digital baseband circuitry 916, transmit circuitry 918, RF circuitry 922, RFFE 924, and antenna panel 926. In some embodiments, the transmit components of the UE 904 may apply spatial filtering to the transmitted data to form transmit beams that are radiated by antenna elements of the antenna panel 926. Similar to the UE 902, the AN 904 may include a host platform 928 coupled to a modem platform 930. The host platform 928 may include an application processing circuitry 932 coupled to the protocol processing circuitry 934 of the modem platform 930. The modem platform may further include digital baseband circuitry 936, transmit circuitry 938, receive circuitry 940, RF circuitry 942, RFFE circuitry 944, and antenna panel 946. The components of the AN 904 may be similar to and substantially interchangeable with similarly named components of the UE 902. In addition to performing data transmission / reception as described above, the components of the AN 904 may perform various logical functions, including RNC functions such as, for example, radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling. Figure 10 is a block diagram 1000 illustrating components in accordance with one or more example embodiments of the present disclosure.

[0126] The components may be capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein. Specifically, FIG. 10 shows a diagrammatic representation of hardware resources including one or more processors (or processor cores) 1010, one or more memory / storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040 or other interface circuitry. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 1002 may be executed to provide an execution environment for one or more network slices / sub-slices to utilize the hardware resources.

[0127] Processor 1010 may include, for example, processor 1012 and processor 1014. Processor 1010 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0128] The memory / storage device 1020 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 1020 may include any type of volatile, non-volatile, or semi-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, etc.

[0129] The communications resources 1030 may include interconnect or network interface controllers, components, or other suitable devices for communicating with one or more peripheral devices 1004, or one or more databases 1006, or other network elements over the network 1008. For example, the communications resources 1030 may include wired communications components (e.g., for coupling via USB, Ethernet, etc.), cellular communications components, NFC components, Bluetooth (or Bluetooth Low Energy) components, Wi-Fi components, and other communications components.

[0130] The instructions 1050 may include software, programs, applications, applets, apps, or other executable code for causing at least one of the processors 1010 to perform any one or more of the methodologies discussed herein. The instructions 1050 may reside completely or partially within at least one of the processors 1010 (e.g., in a cache memory of the processor), the memory / storage device 1020, or any suitable combination thereof. Furthermore, any portion of the instructions 1050 may be transferred to a hardware resource from any combination of the peripheral device 1004 or the database 1006. Thus, the memory of the processor 1010, the memory / storage device 1020, the peripheral device 1004, and the database 1006 are examples of computer-readable and machine-readable media.

[0131] For one or more embodiments, at least one of the components described in one or more of the drawings above may be configured to perform one or more operations, techniques, processes, and / or methods as described in the Examples section below. For example, the baseband circuitry described above in connection with one or more of the drawings above may be configured to operate according to one or more of the examples described below. For another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the drawings above may be configured to operate according to one or more of the examples described in the Examples section below.

[0132] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. As used herein, the terms "computing device," "user device," "communication station," "station," "handheld device," "mobile device," "wireless device," and "user equipment" (UE) refer to wireless communication devices such as mobile phones, smartphones, tablets, netbooks, wireless terminals, laptop computers, femtocells, high data rate (HDR) subscriber stations, access points, printers, point of sale devices, access terminals, or other personal communication system (PCS) devices. The devices may be either mobile or stationary.

[0133] As used within this document, the term "communicate" is intended to include transmitting, or receiving, or both transmitting and receiving. This may be particularly useful in claims describing an organization of data being transmitted by one device and received by another, but where only one function of the devices is required to infringe the claims. Similarly, a two-way exchange of data between two devices (where both devices transmit and receive during the exchange) may be described as "communicating" if only one function of the devices is claimed. When used herein with respect to wireless communication signals, the term "communicating" includes transmitting wireless communication signals and / or receiving wireless communication signals. For example, a wireless communication unit capable of communicating wireless communication signals may include a wireless transmitter for transmitting wireless communication signals to at least one other wireless communication unit and / or a wireless communication receiver for receiving wireless communication signals from at least one other wireless communication unit.

[0134] As used herein, unless otherwise specified, the use of ordinal adjectives such as "first," "second," "third," etc. to describe a common object indicates that different instances of a similar object are merely being referred to, and is not intended to imply that the objects so described must be in a given order, either temporally, spatially, sequentially, or in any other manner.

[0135] As used herein, the term "access point" (AP) may be a fixed station. An access point may also be referred to as an access node, a base station, an evolved Node B (eNodeB), or some other similar terminology known in the art. An access terminal may also be referred to as a mobile station, a user equipment (UE), a wireless communication device, or some other similar terminology known in the art. The embodiments disclosed herein generally relate to wireless networks. Some embodiments may relate to wireless networks that operate according to one of the IEEE 802.11 standards.

[0136] Some embodiments may be used in conjunction with a variety of devices and systems, such as, for example, a personal computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a personal digital assistant (PDA®) device, a handheld PDA® device, an on-board device, an off-board device, a hybrid device, an in-vehicle device, a non-in-vehicle device, a mobile or portable device, a consumer device, a non-mobile or non-portable device, a wireless communication station, a wireless communication device, a wireless access point (AP), a wired or wireless router, a wired or wireless modem, a video device, an audio device, an audio-video (A / V) device, a wired or wireless network, a wireless area network, a wireless video area network (WVAN), a local area network (LAN), a wireless LAN (WLAN), a personal area network (PAN), a wireless PAN (WPAN), etc.

[0137] Some embodiments may be used in conjunction with one-way and / or two-way wireless communication systems, cellular radiotelephone communication systems, mobile telephones, mobile phones, radiotelephones, Personal Communication System (PCS) devices, PDA devices incorporating wireless communication devices, mobile or portable Global Positioning System (GPS) devices, devices incorporating GPS receivers or transceivers or chips, devices incorporating RFID elements or chips, multiple-input multiple-output (MIMO) transceivers or devices, single-input multiple-output (SIMO) transceivers or devices, multiple-input single-output (MISO) transceivers or devices, devices having one or more internal antennas and / or external antennas, digital video broadcast (DVB) devices or systems, multi-standard wireless devices or systems, wired or wireless handheld devices such as smartphones, Wireless Application Protocol (WAP) devices, etc.

[0138] Some embodiments may use any of the following signaling techniques: radio frequency (RF), infrared (IR), frequency division multiplexing (FDM), orthogonal FDM (OFDM), time division multiplexing (TDM), time division multiple access (TDMA), enhanced TDMA (E-TDMA), general packet radio service (GPRS), enhanced GPRS, code division multiple access (CDMA), wideband CDMA (WCDMA), CDMA2000, single carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multitone (DMT), Bluetooth, global time division multiplexing (GTM), time division multiple access (TDMA), time division multiple access (TDMA), time division multiple access (TDMA), time division multiple access (TDMA), time division multiple access (C ... It may be used in conjunction with one or more types of wireless communication signals and / or systems according to one or more wireless communication protocols, such as GPS, Wi-Fi, Wi-Max, ZigBee, Ultra Wideband (UWB), Global System for Mobile Communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, Fifth Generation (5G) mobile networks, 3GPP, Long Term Evolution (LTE), LTE Advanced, Enhanced Data Rates for GSM Evolution (EDGE), etc. Other embodiments may be used in various other devices, systems and / or networks.

[0139] Various embodiments are described below.

[0140] Example 1 may be a system for performing service function chaining classification in a wireless network, the system comprising: a first cellular network device configured to receive Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data comprising an SDAP header; identify a Service Chaining Function (SFC) service identifier in the SDAP header; determine that the SFC service identifier indicates an SFC service profile, the SFC service profile indicating a Quality of Service (QoS) traffic characteristic; identify an SFC traffic flow associated with the SFC service identifier; and transmit the SDAP data to a second cellular network device; and the second cellular network device, where the second cellular network device is configured to receive the SDAP data from the first cellular network device; and transmit the SDAP data to a service function of the system.

[0141] Example 2 may include the system of Example 1 and / or any other example herein, wherein the first cellular network device is a Node B device and the second cellular network device is a communication service function.

[0142] Example 3 may include the system of Example 1 and / or any other example herein, wherein the first cellular network device is a Node B device and the second cellular network device is a user plane function.

[0143] Example 4 may include the system described in any one of Examples 1-3 and / or any other example herein, wherein the SDAP header further includes an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header.

[0144] Example 5 may include the system described in any one of Examples 1-3 and / or any other example herein, wherein the SDAP header further includes an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header.

[0145] Example 6 may include the system described in Example 5 and / or any other example herein, wherein the SFC metadata includes: SFC service classification information; SFC traffic path metadata; SFC parameter and policy updates; application-related information; and UE-related information.

[0146] Example 7 may include the system of Example 1 and / or any other example herein, where the SFC traffic flow shares the same protocol data unit (PDU) session as a non-SFC traffic flow, and the SFC service identifier further indicates an SDAP configuration to facilitate the SFC traffic flow, and modification of SFC traffic mapping rules associated with next-hop transport identifier or encapsulation mapping.

[0147] Example 8 may include the system of Example 1 and / or any other example herein, where a first PDU session for the SFC traffic flow is separate from a second PDU session for a non-SFC traffic flow.

[0148] Example 9 may include the system of Example 1 and / or any other example herein, wherein the SFC traffic flow is not associated with any PDU session.

[0149] Example 10 may include the system of Example 1 and / or any other example herein, wherein the first cellular network device or the second cellular network device is configured to filter the SDAP data based on a packet filter.

[0150] Example 11 may include a computer-readable storage medium comprising instructions that, when executed by a processing circuit in a communications network system, cause the processing circuit to: receive, at a first device of the communications network system, Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data having an SDAP header; identify, at the first device, a Service Chaining Function (SFC) service identifier in the SDAP header; determine, by the first device, the SFC service identifier indicating an SFC service profile, the SFC service profile indicating quality of service (QoS) traffic characteristics; identify, at the first device, an SFC traffic flow associated with the SFC service identifier; and transmit, by the first device, the SDAP data to a second device of the communications network system; receive, at the second device, the SDAP data from the device; and transmit, by the second device, the SDAP data to a service function of the communications network system.

[0151] Example 12 may include the computer-readable medium of Example 11 and / or any other example herein, where the first device is a Node B device and the second device is a communication services function.

[0152] Example 13 may include the computer-readable medium of Example 11 and / or any other example herein, wherein the first device is a Node B device and the second device is a user plane function.

[0153] Example 14 may include the computer-readable medium of any one of Examples 11-13 and / or any other example herein, wherein the SDAP header further includes an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header.

[0154] Example 15 may include the computer-readable medium of any one of Examples 11-13 and / or any other example herein, wherein the SDAP header further includes an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header.

[0155] Example 16 may include the computer-readable medium of Example 15 and / or any other example herein, wherein the SFC metadata includes: SFC service classification information; SFC traffic path metadata; SFC parameter and policy updates; application-related information; and UE-related information.

[0156] Example 17 may include the computer-readable medium of Example 11 and / or any other example herein, where the SFC traffic flow shares the same protocol data unit (PDU) session as a non-SFC traffic flow, and the SFC service identifier further indicates a SDAP configuration to facilitate the SFC traffic flow and a modification of an SFC traffic mapping rule associated with a next-hop transport identifier or encapsulation mapping.

[0157] Example 18 may include the computer-readable medium of Example 11 and / or any other example herein, wherein a first PDU session of the SFC traffic flow is separate from a second PDU session of a non-SFC traffic flow.

[0158] Example 19 may include the computer-readable medium of Example 11 and / or any other example herein, wherein the SFC traffic flow is not associated with any PDU session.

[0159] Example 20 may include a method for performing service function chaining classification in a wireless network, the method including: identifying, by processing circuitry of a session management function (SMF) of a communications network system, a request received from a user equipment (UE) device to establish a service chaining function (SFC) service; selecting, by the processing circuitry of the SMF, a user plane function (UPF) of the communications network system to use for establishing an SFC service classifier for the SFC service based on the request; generating, by the processing circuitry of the SMF, an SFC service classifier rule for the selected UPF, the SFC classifier rule being associated with forwarding traffic; and causing the processing circuitry of the SMF to transmit, to a radio access network (RAN) device of the communications network system, an indication of the SFC service classifier rule and the UPF.

[0160] Example 21 may include the method of Example 20 and / or any other example herein, wherein the SFC classifier rule comprises at least one of packet filter information for packets associated with the SFC service classifier, traffic forwarding rules based on the SFC service classifier, or modification of SFC packets based on the SFC service classifier.

[0161] Example 22 may include the method of example 21 and / or any other example herein, where the modification comprises encapsulating or modifying a packet header.

[0162] Example 23 may include the method of Example 20 and / or any other example herein, further comprising identifying an SFC service context, and wherein the selecting the UPF is based on the SFC service context.

[0163] Example 24 may include an apparatus comprising means for: identifying, with a session management function (SMF) of a communication network system, a request received from a user equipment (UE) device to establish a service chaining function (SFC) service; selecting, by the SMF, a user plane function (UPF) of the communication network system to use for establishing an SFC service classifier for the SFC service based on the request; generating, by the SMF, an SFC service classifier rule for the selected UPF, the SFC classifier rule being associated with forwarding traffic; and causing the SMF to send an indication of the SFC service classifier rule and the UPF to a radio access network (RAN) device of the communication network system.

[0164] Example 25 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of a method described in or related to any one of Examples 1-24, or any other method or process described herein.

[0165] Example 26 may include an apparatus having logic, modules, and / or circuitry for performing one or more elements of a method described in or related to any one of Examples 1-24, or any other method or process described herein.

[0166] Example 27 may include a method, technique, or process as described in or related to any one of Examples 1-24, or any portion or part thereof.

[0167] Example 28 may include an apparatus with one or more processors and one or more computer-readable media having instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process as described in or related to any one of Examples 1-24, or portions thereof.

[0168] Example 29 may include a method of communication in a wireless network as illustrated and described herein.

[0169] Example 30 may include a system for providing wireless communication as illustrated and described herein.

[0170] Example 31 may include a device for providing wireless communication as illustrated and described herein.

[0171] Embodiments according to the present disclosure are particularly disclosed in the appended claims directed to methods, storage media, devices and computer program products, and any feature recited in one claim category, e.g., a method, may also be claimed in another claim category, e.g., a system. Dependencies or references back to the preceding items in the appended claims have been selected for formal reasons only. However, any subject matter that is the result of an intentional reference (especially multiple dependency) back to any previous claim may also be claimed, so that any combination of claims and their features is disclosed and may be claimed without regard to the dependencies selected in the appended claims. Subject matter that may be claimed comprises not only the combination of features set forth in the appended claims, but also any other combination of features in the claims, and each feature recited in the claims may be combined with any other feature or combination of features in the claims. Furthermore, any embodiment and feature described or illustrated in this specification may be claimed in a separate claim and / or in any combination with any of the embodiments and features described or illustrated in this specification or with any of the features of the appended claims. The foregoing description of one or more implementations provides illustration and description, and is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0172] Certain aspects of the present disclosure are described above with reference to blocks and flow diagrams of systems, methods, apparatuses, and / or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, respectively, may be implemented by computer-executable program instructions. Similarly, some blocks of the block diagrams and flow diagrams may not necessarily be executed in the order shown, or may not necessarily be executed at all, according to some implementations.

[0173] These computer executable program instructions may be loaded onto a special purpose computer or other specific machine, processor, or other programmable data processing apparatus to produce a specific machine, such that the instructions executing on the computer, processor, or other programmable data processing apparatus produce means for implementing one or more functions specified in one or more blocks of the flow diagrams. These computer program instructions may also be stored in a computer readable storage medium or memory that can direct a computer or other programmable data processing apparatus to function in a specific manner, such that the instructions stored in the computer readable storage medium produce an article of manufacture including instruction means for implementing one or more functions specified in one or more blocks of the flow diagrams. As one example, a particular implementation may provide a computer program product comprising a computer readable storage medium having computer readable program code or program instructions embodied therein, the computer readable program code adapted to be executed to implement one or more functions specified in one or more blocks of the flow diagrams. Furthermore, computer program instructions may be loaded onto a computer or other programmable data processing apparatus such that the instructions, which execute on the computer or other programmable apparatus, provide elements or steps for implementing the functions specified in one or more blocks of the flow diagrams, and a series of operational elements or steps are executed on the computer or other programmable apparatus to generate a computer-implemented process.

[0174] Thus, the blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions, and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, can be implemented by a dedicated hardware-based computer system that performs the specified functions, elements or steps, or a combination of dedicated hardware and computer instructions.

[0175] In particular, conditional words such as "can," "could," "might," "may," and the like, unless specifically stated otherwise or understood otherwise within the context in which they are used, are generally intended to convey that a particular implementation may include certain features, elements, and / or operations while other implementations do not include them. As such, such conditional words are generally not intended to imply that the features, elements, and / or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for determining whether or not those features, elements, and / or operations should be included or performed in any particular implementation, with or without user input or prompts.

[0176] Many modifications and other implementations of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It will therefore be understood that the disclosure is not limited to the specific implementations disclosed, and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

[0177] For purposes of this document, the following terms and definitions are applicable to the examples and embodiments discussed herein.

[0178] As used herein, the term "circuitry" refers to, is a part of, or includes hardware components configured to provide a described functionality, such as, for example, electronic circuits, logic circuits, processors (shared, dedicated, or groups) and / or memories (shared, dedicated, or groups), application specific integrated circuits (ASICs), field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), etc. In some embodiments, a circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements with program code used to perform the functions of the program code (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0179] As used herein, the term "processor circuit" refers to, is a part of, or includes a circuit capable of continuously and automatically performing a series of arithmetic or logical operations, or recording, storing, and / or transferring digital data. The processing circuit may include one or more processing cores for executing instructions, and one or more memory structures for storing program and data information. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and / or functional processes. The processing circuit may include more hardware accelerators, which may be microprocessors, programmable processing devices, and the like. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. The terms "application circuitry" and / or "baseband circuitry" may be considered and referred to as synonymous with "processor circuitry." As used herein, the term "interface circuitry" refers to, is a part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, and / or a network interface card.

[0180] As used herein, the term "user equipment" or "UE" refers to a device having wireless communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, wireless equipment, reconfigurable wireless equipment, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0181] As used herein, the term "network element" refers to physical or virtualized equipment and / or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with and / or may be referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and / or the like.

[0182] As used herein, the term "computer system" refers to any type of interconnected electronic device, computing device, or components thereof. Additionally, the terms "computer system" and / or "system" may refer to various components of a computer that are communicatively coupled to each other. Additionally, the terms "computer system" and / or "system" may refer to multiple computing devices and / or multiple computing systems that are communicatively coupled to each other and configured to share computing and / or networking resources.

[0183] As used herein, terms such as "appliance" or "computer appliance" refer to a computing device or system that includes program code (e.g., software or firmware) specifically designed to provide specific computing resources. A "virtual appliance" is a virtual machine image implemented by a hypervisor-equipped device that virtualizes or emulates a computing appliance or is otherwise dedicated to providing specific computing resources.

[0184] As used herein, the term "resource" refers to physical or virtual devices, physical or virtual components in a computing environment, and / or physical or virtual components in a particular device, such as, for example, computer devices, mechanical devices, memory space, processor / CPU time, processor / CPU usage, processor and accelerator load, hardware time or usage, power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, databases and applications, and / or workload units. "Hardware resources" may refer to compute, storage, and / or network resources provided by physical hardware elements. "Virtualization resources" may refer to compute, storage, and / or network resources provided by a virtualization infrastructure to applications, devices, systems, etc. The term "network resources" or "communication resources" may refer to resources that are accessible by a computer device / system via a communication network. The term "system resources" may refer to any type of shared entity for providing services and may include computing and / or network resources. A system resource may be viewed as a set of coherent functions, network data objects, or services that reside on a single host or on multiple hosts and are accessible through a clearly identifiable server.

[0185] As used herein, the term "channel" refers to any transmission medium, either tangible or intangible, used to communicate data or data streams. The term "channel" may be synonymous with and / or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and / or any other similar term meaning a path or medium over which data is communicated. Additionally, as used herein, the term "link" refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.

[0186] As used herein, terms such as "instantiate" and "instantiation" refer to the creation of an instance. An "instance" may also refer to a concrete occurrence of an object that may arise, for example, during the execution of program code.

[0187] The terms "coupled" and "communicatively coupled," along with their derivatives, are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, may mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and / or may mean that one or more other elements are coupled or connected between the elements that are described as being coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in contact with each other by means of communication, including through a wired or other interconnected connection scheme, through a wireless communication channel or link, and / or the like.

[0188] The term "information element" refers to an element of a structure that contains one or more fields. The term "field" refers to the individual contents of an information element or the data element that contains the contents.

[0189] Unless used differently herein, the terms, definitions, and abbreviations may be consistent with those defined in 3GPP® TR 21.905 v16.0.0 (2019-06) and / or any other 3GPP® standards. For purposes of this document, the following abbreviations (shown in Table 1) may apply to the examples and embodiments discussed herein: [Other possible items] [Item 1] 1. A system for performing service capability chaining classification in a wireless network, the system comprising: A first cellular network device, the first cellular network device comprising: receiving Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data comprising an SDAP header; Identifying a service chaining function (SFC) service identifier in the SDAP header; determining that the SFC service identifier is indicative of an SFC service profile, the SFC service profile indicative of a Quality of Service (QoS) traffic characteristic; Identifying an SFC traffic flow associated with the SFC service identifier; and Transmitting the SDAP data to a second cellular network device a first cellular network device configured to: the second cellular network device, receiving the SDAP data from the first cellular network device; and Sending the SDAP data to a service function of the system the second cellular network device configured A system comprising: [Item 2] 2. The system of claim 1, wherein the first cellular network device is a Node B device and the second cellular network device is a communication service function. [Item 3] 2. The system of claim 1, wherein the first cellular network device is a Node B device and the second cellular network device is a user plane function. [Item 4] The system of any one of items 1 to 3, wherein the SDAP header further includes an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header. [Item 5] The system of any one of items 1 to 3, wherein the SDAP header further includes an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header. [Item 6] The SFC metadata is: SFC service classification information; SFC Traffic Path Metadata; SFC parameters and policy updates; Application-related information; and UE related information 6. The system according to item 5, comprising: [Item 7] 2. The system of claim 1, wherein the SFC traffic flow shares the same protocol data unit (PDU) session as a non-SFC traffic flow, and the SFC service identifier further indicates an SDAP configuration to facilitate the SFC traffic flow and a modification of an SFC traffic mapping rule associated with a next-hop transport identifier or encapsulation mapping. [Item 8] 2. The system of claim 1, wherein a first PDU session for the SFC traffic flow is separate from a second PDU session for a non-SFC traffic flow. [Item 9] 2. The system of item 1, wherein the SFC traffic flow is not associated with any PDU session. [Item 10] 2. The system of claim 1, wherein the first cellular network device or the second cellular network device is configured to filter the SDAP data based on a packet filter. [Item 11] In a processing circuit of a communication network system, when the processing circuit executes an instruction, receiving, at a first device of the communication network system, Service Data Adaptation Protocol (SDAP) data from a User Equipment (UE) device, the SDAP data having an SDAP header; Identifying, at the first device, a Service Chaining Function (SFC) service identifier in the SDAP header; determining, by the first device, that the SFC service identifier is indicative of an SFC service profile, the SFC service profile being indicative of a Quality of Service (QoS) traffic characteristic; Identifying, at the first device, an SFC traffic flow associated with the SFC service identifier; and transmitting, by the first device, the SDAP data to a second device of the communication network system; receiving, at the second device, the SDAP data from the device; and Transmitting the SDAP data by the second device to a service function of the communication network system. A computer-readable storage medium comprising the instructions to cause a [Item 12] Item 12. The computer-readable storage medium of item 11, wherein the first device is a Node B device and the second device is a communication service function. [Item 13] Item 12. The computer-readable storage medium of item 11, wherein the first device is a Node B device and the second device is a user plane function. [Item 14] 14. The computer-readable storage medium of any one of items 11 to 13, wherein the SDAP header further includes an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header. [Item 15] 14. The computer-readable storage medium of any one of items 11 to 13, wherein the SDAP header further includes an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header. [Item 16] The SFC metadata is SFC service classification information; SFC Traffic Path Metadata; SFC parameters and policy updates; Application-related information; and UE related information Item 16. The computer-readable storage medium of item 15, having: [Item 17] Item 12. The computer-readable storage medium of item 11, wherein the SFC traffic flow shares the same protocol data unit (PDU) session as a non-SFC traffic flow, and the SFC service identifier further indicates an SDAP configuration to facilitate the SFC traffic flow and a modification of an SFC traffic mapping rule associated with a next-hop transport identifier or encapsulation mapping. [Item 18] Item 12. The computer-readable storage medium of item 11, wherein the first PDU session of the SFC traffic flow is separate from the second PDU session of the non-SFC traffic flow. [Item 19] Item 12. The computer-readable storage medium of item 11, wherein the SFC traffic flow is not associated with any PDU session. [Item 20] 1. A method for performing service capability chaining classification in a wireless network, the method comprising: identifying, by a processing circuit of a Session Management Function (SMF) of the communication network system, a request received from a User Equipment (UE) device for establishing a Service Chaining Function (SFC) service; selecting, by the processing circuitry of the SMF, a User Plane Function (UPF) of the communication network system to be used for establishing an SFC service classifier for the SFC service based on the request; generating, by the processing circuitry of the SMF, an SFC service classifier rule for the selected UPF, the SFC classifier rule being associated with forwarding traffic; and causing the processing circuitry of the SMF to transmit the SFC service classifier rules and an indication of the UPF to a Radio Access Network (RAN) device of the communication network system. A method for providing the above. [Item 21] 21. The method of claim 20, wherein the SFC classifier rules comprise at least one of packet filter information for packets associated with the SFC service classifier, traffic forwarding rules based on the SFC service classifier, or modification of SFC packets based on the SFC service classifier. [Item 22] 22. The method of claim 21, wherein the modification comprises encapsulation or modification of a packet header. [Item 23] 21. The method of claim 20, further comprising identifying an SFC service context, and selecting the UPF is based on the SFC service context. [Item 24] A computer-readable storage medium comprising instructions for performing the method according to any one of items 20 to 23. [Item 25] An apparatus comprising means for carrying out the method according to any one of Items 20 to 23.

[0190] Table 1: Abbreviations: [Table 1A] [Table 1B] [Table 1C] [Table 1D] [Table 1E] [Table 1F] [Table 1G]

Table 1H

Table 1I

Table 1J

Table 1K

Claims

1. 1. A system for performing service capability chaining classification in a wireless network, the system comprising:

1. A first cellular network device, the first cellular network device comprising: receiving Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data comprising an SDAP header; Identifying a Service Chaining Function (SFC) service identifier in the SDAP header; determining that the SFC service identifier indicates an SFC service profile; Identifying an SFC traffic flow associated with the SFC service identifier; and Transmitting the SDAP data to a second cellular network device the first cellular network device; and The second cellular network device, wherein the second cellular network device: receiving the SDAP data from the first cellular network device; and Sending the SDAP data to a service function of the system the second cellular network device is configured to A system comprising:

2. The system of claim 1 , wherein the first cellular network device is a Node B device and the second cellular network device is a communication service function.

3. The system of claim 1 , wherein the first cellular network device is a Node B device and the second cellular network device is a user plane function.

4. The system of any one of claims 1 to 3, wherein the SDAP header further comprises an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header.

5. The system of any one of claims 1 to 3, wherein the SDAP header further comprises an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header.

6. The SFC metadata includes: SFC service classification information; SFC traffic path metadata; SFC parameters and policy updates; Application-related information; and UE related information The system of claim 5 , further comprising:

7. 2. The system of claim 1, wherein the SFC traffic flows share the same protocol data unit (PDU) session as non-SFC traffic flows, and the SFC service identifier further indicates an SDAP configuration to facilitate the SFC traffic flows and modifications to SFC traffic mapping rules associated with next-hop transport identifier or encapsulation mapping.

8. 2. The system of claim 1, wherein the first PDU session of the SFC traffic flow is separate from a second PDU session of a non-SFC traffic flow.

9. The system of claim 1 , wherein the SFC traffic flow is not associated with any PDU session.

10. The system of claim 1 , wherein the first cellular network device or the second cellular network device is configured to filter the SDAP data based on a packet filter.

11. In a processing circuit of a communication network system, when the processing circuit executes an instruction, receiving, at a first device of the communication network system, Service Data Adaptation Protocol (SDAP) data from a user equipment (UE) device, the SDAP data having an SDAP header; Identifying, at the first device, a Service Chaining Function (SFC) service identifier in the SDAP header; determining, by the first device, that the SFC service identifier is indicative of an SFC service profile; Identifying, at the first device, an SFC traffic flow associated with the SFC service identifier; transmitting, by the first device, the SDAP data to a second device of the communication network system; receiving, at the second device, the SDAP data from the first device; and Transmitting the SDAP data by the second device to a service function of the communication network system. A computer program comprising the instructions to cause a computer to

12. The computer program product of claim 11 , wherein the first device is a Node B device and the second device is a communication service function.

13. The computer program product of claim 11 , wherein the first device is a Node B device and the second device is a user plane function.

14. 12. The computer program product of claim 11, wherein the SDAP header further comprises an SFC indicator field set to 1 to indicate that the SFC service identifier is included in the SDAP header.

15. 12. The computer program product of claim 11, wherein the SDAP header further comprises an SFC metadata indicator field to indicate that SFC metadata is included within the SDAP header.

16. The SFC metadata includes: SFC service classification information; SFC traffic path metadata; SFC parameters and policy updates; Application-related information; and UE related information 16. The computer program of claim 15, comprising:

17. 12. The computer program product of claim 11, wherein the SFC traffic flow shares the same protocol data unit (PDU) session as a non-SFC traffic flow, and the SFC service identifier further indicates an SDAP configuration to facilitate the SFC traffic flow and modification of SFC traffic mapping rules associated with next-hop transport identifier or encapsulation mapping.

18. 12. The computer program product of claim 11, wherein the first PDU session of the SFC traffic flow is separate from a second PDU session of a non-SFC traffic flow.

19. The computer program product of claim 11 , wherein the SFC traffic flow is not associated with any PDU session.

20. A computer-readable storage medium storing a computer program according to any one of claims 11 to 19.

21. A method for performing service capability chaining classification in a wireless network, the method comprising: receiving, by a first device of the communication network system, from a user equipment (UE) device, Service Data Adaptation Protocol (SDAP) data having an SDAP header; the first device identifying a Service Chaining Function (SFC) service identifier in the SDAP header; determining, by the first device, that the SFC service identifier indicates an SFC service profile; the first device identifying an SFC traffic flow associated with the SFC service identifier; transmitting the SDAP data from the first device to a second device of the communication network system; receiving the SDAP data from the first device by the second device; and said second device transmitting said SDAP data to a service function of said communication network system. A method for providing the above.

Images