Object-oriented 6g network service support system, and method

Abstract

The present invention belongs to the technical field of communications, and specifically relates to an object-oriented 6G network service support system. The system comprises a service object package (SOP) layer, a functional object protocol (FOP) layer, a resource object modeling (ROM) layer, object orchestration and scheduling (O-ORCH) and network virtual entity management (N-VEM). The support system provided in the present invention provides a foundation for various functions of a flexible network by means of abstracting network components to construct multi-object collaboration in different forms of different service objects such as network objects, network package, object inheritance and aggregation, and polymorphism. The support system in the present invention supports a cross-entity inter-object multi-level object service invocation mode, and instantiates, into inter-object communications, the communication between a UE and a network, the communication between a UE and a UE, and the communication between a network element and a network element, both communication parties construct a communication object pair, which is divided into peer-layer communication and non-peer-layer communication on the basis of invocation hierarchy, thereby implementing flexible resource management, scheduling, and service collaboration.

Description

An object-oriented 6G network service support system and method Technical Field

[0001] This invention belongs to the field of communication technology, and specifically relates to an object-oriented 6G network service support system and method. Background Technology

[0002] The goal of 6G is to empower a ubiquitous and intelligent information society, integrating communication, computing, sensing, and intelligence to establish a ubiquitous mobile communication network across air, space, and sea, achieving high-speed broadband communication with global ubiquitous coverage. Simultaneously, the diversification of data sources, applications, communication methods, and computing demands that 6G possess capabilities in areas such as intelligence and flexible service / business support. It can be seen that 6G is not only a product of the combination of mobile communication, computer, big data, and artificial intelligence technologies (ICDT), but is also evolving towards DOICT, building a new network foundation: simplifying field network construction through CT; achieving high reliability through OT and deep collaboration with industrial protocols; realizing intelligence through DT, ensuring a low-latency experience through closed-loop guarantees; and using IT for more industrial applications, reducing construction costs and enabling flexible networking.

[0003] Many emerging scenarios require networks to achieve seamless coverage, ultimate connectivity, integrated "sensing, computing, and communication," parallel interaction of digital twins, and intrinsic intelligence, which 5G cannot fully match. Therefore, based on typical 5G scenarios (eMBB, ULRRC, and mMTC), 6G needs to support three enhancement technologies: uMBB (ubiquitous mobile broadband), ULBC (ultra-reliable low-latency broadband communication), and mULC (massive ultra-reliable low-latency communication).

[0004] The key characteristic that future networks need to possess is flexibility, while existing technologies such as 5G suffer from problems such as rigid network architecture, rigid protocol stack layers, coarse-grained network resource management, and limited scope of collaboration between network functional components. The flexibility requirements of 6G networks are mainly reflected in the following three aspects:

[0005] Flexible business and service support: At the application and service layer, a user-centric network is implemented. The network serves the user, therefore, the network design must fully consider the user's needs, activate network service support functions on demand, and enable the network to "move" with the user and service capabilities to "migrate" with business scenarios.

[0006] Flexible resource management and scheduling: At the resource layer, the network should have the ability to schedule distributed network resources on demand. To meet the demands of new scenarios and applications for data traffic and transmission latency, computing, storage, and transmission resources will be distributed across every node in the end-to-end network. This will enable on-demand allocation and flexible scheduling of resources between the cloud, network, and edge, thereby achieving network flexibility at the resource level.

[0007] Flexible and Adaptive Network Architecture: In 5G networks, the air interface protocol adopts a layered model, including the physical layer, media access control (MAC) layer, radio link control (RLC) layer, and packet data convergence protocol (PDCP) layer. All service data must be processed through these layers. Each layer introduces specific latency, making latency a bottleneck. Furthermore, at the network function layer, the network should be able to flexibly and independently expand network element capabilities and rapidly iterate and evolve software functions. Specifically, 6G networks should be end-to-end SBA (Service-Based Architecture). Therefore, compared to the SBA CN (Service-Based Networking) already largely completed in 5G networks, 6G needs to focus on the service-oriented architecture of the RAN (Radio Access Controller). Summary of the Invention

[0008] To address the aforementioned problems, this invention provides an object-oriented network service support system, characterized by comprising: a Service Encapsulation Layer (SOP), a Functional Protocol Layer (FOP), a Resource Modeling Layer (ROM), an Object Orchestration and Scheduling Layer (O-ORCH), and a Network Virtual Entity Management Layer (N-VEM);

[0009] Service Object Encapsulation Layer (SOP): The control plane, based on service objects, provides real-time control of business data flow to support various application services and manage user registration, authentication, and mobility; the user plane, based on service objects, handles business data flow transmission and processing; and the information plane, based on service objects, provides necessary auxiliary information for the control and user planes.

[0010] The service objects are categorized into user plane service objects, control plane service objects, and information plane service objects. User plane service objects include sub-module-level objects such as QoS profiles for service data, data flow control, and packet routing and forwarding management, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of module-level objects. Control plane service objects include service control-related objects and their capability management for UE access management, mobility management, session management, security management, and slicing management, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of module-level objects. Information plane service objects include sub-module-level objects such as user service-related information analysis, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of module-level objects.

[0011] Functional Object Protocol Layer (FOP): The control plane is based on functional objects and is used for configuration and control between objects; the user plane is based on functional objects and is used for carrying user business information flow transmission; the information plane is based on functional objects and is used to provide necessary auxiliary information for the control plane and user plane.

[0012] The functional objects are divided into user plane functional objects, control plane functional objects, and information plane functional objects. User plane functional objects include sub-module-level objects such as mapping service data and QoS flow, mapping QoS flow and DRB, PDU data encapsulation and decapsulation, transport block (TB) multiplexing and demultiplexing, physical signal processing, and latency- and deterministic-sensitive data QoS assurance, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of module-level objects. Control plane functional objects include sub-module-level objects related to UE radio configuration signaling process control, resource allocation and UE scheduling control, link adaptation, power control, and logical channel priority mapping management, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of sub-module-level objects. Information plane functional objects include sub-module-level objects such as channel / environment measurement and reference signal-related information, as well as UE-level and service-level aggregation objects. Aggregate objects are implemented through derivation and inheritance of module-level objects.

[0013] Resource Object Modeling Layer (ROM): The control plane is based on resource objects and is used for real-time control of resource objects, responsible for resource model creation and management; the execution plane is based on resource objects and serves as the carrier of signal processing, acting as the execution object entity to perform specific business operations; the information plane is based on resource objects and is used to monitor the status of resource objects, etc., to assist the control plane and execution plane in making dynamic adjustments.

[0014] Resource objects are categorized into execution plane resource objects, control plane resource objects, and information plane resource objects. Execution plane resource objects include resource unit-level objects such as RF Chain, spectrum, and computing power, as well as business-level aggregate objects constructed from multiple objects. Aggregate objects are implemented through derivation and inheritance of unit-level objects. Control plane functional objects include sub-module-level objects related to resource control, such as computing resource configuration and management control, as well as aggregate objects that combine multiple objects as needed for business processing. Aggregate objects are implemented through derivation and inheritance of sub-module-level objects. Information plane functional objects include sub-module-level objects such as object status monitoring, as well as aggregate objects that combine multiple objects as needed for business processing. Aggregate objects are implemented through derivation and inheritance of sub-module-level objects.

[0015] The object orchestration and scheduling O-ORCH periodically updates the service status (service status of each object in each layer) reported by the service encapsulation layer SOP of multiple network entities. Multiple network entities within an autonomous system share a single object orchestration and scheduling O-ORCH. The object orchestration and scheduling O-ORCH performs object management and scheduling on one or more network entities according to business / service requirements.

[0016] The Network Virtual / Entity Management (N-VEM) is responsible for the management of network element nodes in the network, including the management of physical network elements and virtual network element nodes. The physical network elements are user equipment (UE) and network equipment nodes, and the virtual network element nodes are digital twins based on physical network elements. Multiple autonomous systems share one Network Virtual / Entity Management (N-VEM).

[0017] Furthermore, the Service Encapsulation Layer (SOP) includes the Authentication Server Function Module (AUSF), Access and Mobility Management Function Module (AMF), Network Service Presentation Function Module (NEF), Network Storage Function Module (NRF), Network Slice Admission Control Function Module (NSACF), Network Slice Authentication and Authorization Function Module (NSSAAF), Network Slice Selection Function Module (NSSF), Policy Control Function Module (PCF), Session Management Function Module (SMF), Non-Seamless WLAN Offload Function Module (NSWOF), Edge Application Service Discovery Function Module (EASDF), Object Service Capability Management Module (OSCM), User Plane Function Module (UPF), and Data Analysis Function Module (DAF).

[0018] Furthermore, the Functional Protocol Layer (FOP) includes...

[0019] The L1 physical sublayer PHY is used to utilize resource objects (wireless resources, AI model resources, etc.) provided by the resource object modeling layer for multiple access, providing physical channels, modulation and demodulation, channel coding and decoding, physical layer processes, physical layer measurements, and anti-interference processing.

[0020] The L2 link sublayer, including the Media Access Control (MAC) sublayer, is used for segmentation and reassembly of Service Data Units (SDUs), mapping between logical channels and transport channels, multiplexing and demultiplexing of several logical channel SDUs and a transport block (TB), user equipment scheduling, resource allocation, link adaptation and power control, HARQ error correction, logical channel priority sorting and processing, and user equipment data priority processing.

[0021] The L3 logical sublayer includes the Service Data Adaptation sublayer (SDA), the Packet Data Convergence Protocol sublayer (PDCP), and the Radio Link Control sublayer (RLC). The Radio Data Adaptation sublayer (SDA) includes a Time-Sensitive Control (TSC) functional unit and a QoS Flow Handling (QFH) functional unit. The TSC is used to implement deterministic transmission control of services, and the QFH is used to implement the mapping between QoS Flow and DRB, and to mark the QoS Flow ID of UL and DL packets.

[0022] The L3 logical sublayer control plane is responsible for the signaling flow functions of the UE's radio configuration; the user plane is responsible for the mapping of service data and QoS, the mapping of QoS and data radio bearers or signaling radio bearers DRB / SRB, service data flow control and transmission, deterministic transmission control, unified packet processing of network control signaling and user data, and interaction with the L2 link sublayer.

[0023] Furthermore, during service data transmission, the Functional Protocol Layer (FOP) can dynamically bypass one or more sublayers of PDCP, RLC, and MAC, or bypass some functional units of SDA, based on the QoS requirements of the service data.

[0024] Furthermore, the resource modeling layer ROM includes an RMOM functional unit responsible for the management and maintenance of resource model objects, a RORM functional unit responsible for the establishment, association, modification and maintenance of resource object relationships, a ROSCH functional unit responsible for real-time scheduling of resource objects, a resource object routing RORU, and an OSMON functional unit responsible for monitoring the status of resource objects.

[0025] Furthermore, the ROSCH functional unit implements internal object scheduling of the control plane, execution plane, and information plane based on the object orchestration and scheduling instructions of O-ORCH.

[0026] Furthermore, the object orchestration and scheduling (O-ORCH) includes an object service authorization management (OSAU) module that manages the configuration of external service licenses for managed objects; an object allocation and recycling (OARE) module that allocates and reclaims objects at each layer of an entity based on object status and service requirement information; and an object status management (OSM) module that is responsible for collecting, updating, and recording object status and capability information.

[0027] Furthermore, the Network Virtual / Entity Management (N-VEM) includes an Unstructured Data Storage Function Module (UDSF), a UE Radio Management Function (UCMF), a Billing Function Module (CHF), a Unified Data Management Function (UDM), a Message Frame Adapter Function Module (MFAF), and a Digital Virtual / Twin Network Management (DVNM).

[0028] Furthermore, the Service Object Encapsulation Layer (SOP), Functional Object Protocol Layer (FOP), Object Orchestration and Scheduling (O-ORCH), and Network Virtual / Entity Management (N-VEM) are all equipped with an Intrinsic Intelligent Agent (AI Agent), and the Resource Object Modeling Layer (ROM) is equipped with an Intelligent Engine (AI Engine). The Intrinsic Intelligent Agent (AI Agent) and the Intelligent Engine (AI Engine) collaborate through object calls at each layer to support AI-type business / services.

[0029] The present invention also provides a service support method based on the above-mentioned object-oriented network service support system:

[0030] This includes network entities A and B existing within the same autonomous system, the service requirements of a certain functional layer (SOP or FOP) of entity A that processes a certain service, and the service processing capabilities of each functional layer of entity A. It determines the service support that needs to initiate a specific functional layer call to other entities and initiates the request to the object orchestration and scheduling module O-ORCH.

[0031] After receiving a business support request, the object orchestration and scheduling system makes an object allocation and scheduling decision based on the updated service status of entities A and B, and returns the allocation result to entity A.

[0032] After receiving the object allocation and scheduling decision, entity A updates and stores the capabilities of each functional layer of entity B, and at the same time initiates a request to entity B to call a specific functional layer; after receiving the scheduling request from entity A, the specific functional layer of entity B returns call confirmation information to entity A and establishes a service function connection with entity A, thereby completing the business support for the specific functional layer call.

[0033] Furthermore, the method by which network entity A schedules the functional layer objects of network entity B includes peer-to-peer calls and non-peer-to-peer calls; the peer-to-peer call refers to network entity A's SOP or FOP scheduling the corresponding SOP or FOP resources of network entity B; the non-peer-to-peer call refers to network entity A's SOP scheduling the FOP resources of network entity B or network entity A's FOP scheduling the ROM resources of network entity B.

[0034] Furthermore, the present invention also provides a third-party service authorization and guarantee credit method based on the above-mentioned object-oriented network service support system:

[0035] When an entity needs to initiate a service / business authorization request that it cannot decide on its own using O-ORCH, the object orchestration and scheduling entity will forward the service / business authorization request to the network virtual entity management entity. When the network virtual entity management entity cannot decide on its own, it will send a credit query to a trusted third party, and the trusted third party will return the query result based on its credit information.

[0036] The network virtual entity management determines whether to authorize based on the query results and sends the results to the object orchestration and scheduling entity. The object orchestration and scheduling network element issues instructions to each functional layer on whether to allow services / businesses based on the judgment results.

[0037] In summary, the present invention has at least one of the following beneficial effects:

[0038] 1. The network system provided by this invention abstracts network components, including resources, protocol layers, devices, and network elements, into different forms of operations based on network objects (resource objects, functional objects, and service objects; object creation and destruction are based on resource types and application scenario requirements), network encapsulation (programmable slices, network programming APIs), object inheritance and aggregation (extending object attributes and methods through inheritance), and polymorphism (autonomous domain objects (air-ground, space-air, private networks, etc.), physical world, digital world, and biological consciousness world), providing a foundation for the various functions of flexible networks.

[0039] 2. The present invention provides an object-oriented network service support system that supports multi-level object service invocation mode between cross-entity objects. It instantiates the communication between UE and network, between UE and UE, and between network elements as communication between objects. The two parties in the communication construct a communication object tuple (e.g., UE1 object <---> UE2 object). Based on the invocation level, it is divided into peer-to-peer communication and non-peer-to-peer communication, realizing flexible resource management, scheduling and service collaboration.

[0040] 3. The network system provided by this invention features a bypassable network design, enabling a network hierarchy structure that adapts to changing service scenarios. This includes scenario-adaptive changes in the protocol stack architecture, i.e., a dynamically variable protocol stack structure, with some protocol layers capable of bypassing (such as RLC layer bypass technology). Through dynamic awareness of service types, the network protocol architecture adaptively adjusts or the network and terminals negotiate adjustments, thus constructing a flexible and adaptive network architecture.

[0041] 4. This invention designs a multi-faceted unified wireless protocol stack, which includes a control plane, a user plane, and an information plane. Due to the need for concurrent service processing, the network supports multi-faceted aggregation processing, i.e., pipelined concurrent processing of control plane, user plane, and information plane processes. Once the control plane process completes at a certain node, the user plane process can begin. The information plane and user plane processes are aggregated at appropriate nodes. This aggregation point is located above the functional protocol layer, meaning it can converge to the logical layer's user plane for unified service layer integration processing according to service needs. If there is no aggregation requirement, the user plane and information plane are processed independently, further enhancing the management and scheduling of flexible resources.

[0042] 5. The present invention also provides a service call guarantee and credit system architecture between business and objects, which supports secure licensing for cross-entity object service calls by introducing a third-party or public credit center, and can also support credit licensing for user businesses. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 shows the overall network architecture of this invention;

[0045] Figure 2 shows the overall framework of business collaboration in the network support system of this invention;

[0046] Figure 3 shows an example of a network autonomous domain deployment architecture;

[0047] Figure 4 shows the network logical entity architecture;

[0048] Figure 5. Mapping ratio between network components;

[0049] Figure 6. Functional and system architecture of the SOP service object encapsulation layer;

[0050] Figure 7. Control flow of QoS policy in the SOP control plane of the service encapsulation layer;

[0051] Figure 8. Service encapsulation layer SOP user plane business data flow processing flow;

[0052] Figure 9. QoS profile service type breakdown diagram;

[0053] Figure 10. Definition of the QoS-aware profile object;

[0054] Figure 11. Definition of computing power QoS profile object;

[0055] Figure 12. Definition of digital twin QoS profile object;

[0056] Figure 13 AI QoS profile object definition;

[0057] Figure 14. Functional Protocol Layer (FOP) framework structure;

[0058] Figure 15. Functional Protocol Layer (FOP) Control Plane Protocol Stack;

[0059] Figure 16. Functional Protocol Layer (FOP) User Plane Protocol Stack;

[0060] Figure 17. Functional Protocol Layer (FOP) Information Plane Protocol Stack;

[0061] Figure 18. Functional Protocol Layer (FOP) channel structure diagram;

[0062] Figure 19. Example of signal processing flow in the physical sublayer of the AI-assisted function protocol layer FOP;

[0063] Figure 20. Functional Protocol Layer (FOP) downlink protocol stack architecture;

[0064] Figure 21. Functional Protocol Layer (FOP) uplink protocol stack architecture;

[0065] Figure 22 Bypassable protocol stack architecture – Downlink;

[0066] Figure 23 Bypassable Protocol Stack Architecture – Uplink;

[0067] Figure 24 Example of RLC bypass process;

[0068] Figure 25 Example of DL MAC PDU;

[0069] Figure 26 Example of UL MAC PDU;

[0070] Figure 27 Framework structure of ROM resource object modeling layer;

[0071] Figure 28. Resource object collaboration relationships;

[0072] Figure 29 ROM Three-Sided Collaboration Framework Flow;

[0073] Figure 30 Functional framework of O-ORCH network for object orchestration and scheduling;

[0074] Figure 31 shows the O-ORCH functional module and its collaboration process with SOP / FOP / ROM.

[0075] Figure 32 N-VEM functional framework;

[0076] Figure 33 Overall processing flow of services such as intelligent sensing and computing;

[0077] Figure 34 Service call process for peer-to-peer objects (A.SOP - B.SOP);

[0078] Figure 35 Cross-layer object call service flow (A. SOP calls B. FOP layer object);

[0079] Figure 36 Cross-layer object call service flow (A. FOP calls B. ROM layer object);

[0080] Figure 37 Service security trust framework process;

[0081] Figure 38. Example of AI business / service processing flow. Detailed Implementation

[0082] The present invention will be further described in detail below with reference to the accompanying drawings. Example 1:

[0083] The invention provides an object-oriented network service support system, whose network architecture is shown in Figure 1. It includes a Service Encapsulation Layer (SOP), a Functional Protocol Layer (FOP), a Resource Modeling Layer (ROM), an Object Orchestration and Scheduling Layer (O-ORCH), and a Network Virtual Entity Management Layer (N-VEM). The service processing framework of this network framework is shown in Figure 2.

[0084] This network architecture is applied in one or more autonomous systems (ASAs), each containing multiple entities / network entities. A deployment example of a network AS is shown in Figure 3. Figures 4 and 5 show the network logical entity architecture within an AS, the interaction interfaces used between functional layers, functional units, and entities, and the mapping ratio between network components. The interaction interfaces include:

[0085] Vm: Operation and maintenance, the interface between the global data center node N-VEM and the network nodes it manages / serves;

[0086] Vo: The interface between the object orchestration and scheduling function entity O-ORCH and the functional protocol layer entity FOP and the service encapsulation layer entity SOP node it controls;

[0087] Hn: Interface between the SOP control plane and the user plane functional entities in the service encapsulation layer;

[0088] Vx: The interface between FOP and SOP units;

[0089] Uu: Wireless air interface;

[0090] Nx: The interface between the Service Packet Operating System (SOP) and the business nodes.

[0091] The Service Encapsulation Layer (SOP) comprises multiple functional units, including the Authentication Server Function Module (AUSF), Access and Mobility Management Function Module (AMF), Network Service Presentation Function Module (NEF), Network Storage Function Module (NRF), Network Slice Admission Control Function Module (NSACF), Network Slice Authentication and Authorization Function Module (NSSAAF), Network Slice Selection Function (NSSF), Policy Control Function Module (PCF), Session Management Function Module (SMF), Non-Seamless WLAN Offload Function Module (NSWOF), Edge Application Service Discovery Function Module (EASDF), Object Service Capability Management Module (OSCM), User Plane Function Module (UPF), and Data Analysis Function Module (DAF).

[0092] Figure 6 shows the functionalities and architecture of each functional unit participating in the SOP service encapsulation layer. The names and functions of each functional unit are as follows:

[0093] Authentication Server Function (AUSF):

[0094] Verify the network functionality of the UE for the requester;

[0095] Provide key materials to the requester's network functions;

[0096] A list of guidance information for protecting the network functions of the requester.

[0097] Access and Mobility Management Function (AMF):

[0098] Registration, connection, accessibility, and mobility management;

[0099] Provides a session management message transmission channel for UE and SMF;

[0100] Provide authentication and authorization functions for users when they access the platform;

[0101] Access point for the core network control plane of terminals and wireless systems.

[0102] Network Exposure Function (NEF):

[0103] Information can be stored in the NDR, and information can also be retrieved from the NDR;

[0104] Provide appropriate security measures to ensure the security of external applications used on the 6G network;

[0105] The conversion of relevant information between 6G internal and external systems;

[0106] Obtain relevant information about other network elements.

[0107] Network Repository Function (NRF)

[0108] Business discovery functionality;

[0109] Maintain the characteristics of available network element instances and their supported service capabilities;

[0110] Characteristic parameters of storage network elements.

[0111] Network Slice Admission Control Function (NSACF):

[0112] Monitor and control the number of UEs registered on each network chip;

[0113] Monitor and control the number of PDU sessions established for each network segment;

[0114] Event-based network slice status notifications and network function reports to users.

[0115] Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF).

[0116] Authentication and authorization of specific network slices

[0117] Network Slice Selection Function (NSSF):

[0118] The network slice instance that the UE is allowed to access is determined based on the UE's slice selection assistance information, subscription information, etc.

[0119] Identify the allowed NSSAIs and, if necessary, map them to the signed S-NSSAIs;

[0120] Determine the configured NSSAI, and map it to the signed S-NSSAI if necessary;

[0121] Determine the set of AMFs to serve the UE.

[0122] Policy Control Function (PCF):

[0123] Supports a unified policy framework and manages network behavior;

[0124] Provide policy rules to network entities;

[0125] Access subscription information for the Unified Data Warehouse (UDR).

[0126] Session Management Function (SMF):

[0127] Session Management: Responsible for tunnel maintenance, IP address allocation and management, UP function selection, and policy implementation;

[0128] QoS includes control, billing data collection, and roaming.

[0129] Legitimate wiretapping;

[0130] Downlink data notification.

[0131] Non-Seamless WLAN Offload Function (NSWOF):

[0132] NSWO authentication;

[0133] Edge Application Server Discovery Function (EASDF) is a feature for discovering edge application services.

[0134] Process DNS messages according to SMF instructions, including exchanging DNS messages from the UE; forwarding DNS messages to C-DNS or L-DNS for DNS queries, etc.

[0135] Object Service Capability Management (OSCM):

[0136] Configure, query, and maintain object service capabilities.

[0137] User Plane Function (UPF):

[0138] Anchor points for intra-RAT movement;

[0139] Data packet routing, forwarding, monitoring, and QoS processing;

[0140] Traffic statistics and reporting.

[0141] Data Analytics Function (DAF):

[0142] Responsible for collecting and analyzing data, and providing users with the generated analysis results.

[0143] Based on the above functional units, the control plane of the Service Encapsulation Layer (SOP) can control the business data flow in real time to support various application services and manage user registration, authentication, and mobility; the user plane can process business data flow transmission; and the information plane provides necessary auxiliary information for the control plane and the user plane.

[0144] The Service Encapsulation Layer (SOP) control plane provides programmable APIs for network services, existing as an interface layer. It is divided into internal and external API interfaces. The internal API is mainly used for network programmable control and service authorization management. The external API primarily provides services to service users, including user registration, authentication, mobility management, QoS policy control, and PDU session management. Its QoS policy control flow is shown in Figure 7, with a specific control example provided:

[0145] 1. The APP provides the PCF with application-layer business requirements, which include flow description information for business data flow detection and QoS-related requirements, such as bandwidth requirements and service types.

[0146] 2. PCF formulates PCC rules based on information collected from various channels such as SMF, AMF, NWDAF, and UDR, as well as pre-configured information on PCF.

[0147] 3. The PCF sends the PCC rules to the SMF, where the PCC rules are at the Business Data Flow (SDF) level.

[0148] 4. Based on the received PCC rules, the SMF's own configuration information, and the UE subscription information obtained from the UDM, the SMF determines the appropriate QoS flow to transmit the service data flow corresponding to the PCC rules.

[0149] Step 5. SMF will determine the following information for each QoS flow:

[0150] (1) QoS profile, sent to a base station for mapping QoS Flow to DRB.

[0151] (2) QoS rule, sent to the UE for use, mainly used for mapping uplink data SDF to QoS Flow.

[0152] (3) PDR packet detection rules are mainly used for mapping downlink data SDF to QoS Flow, and uplink data in the network.

[0153] Further detection and control on the side.

[0154] (4) QoS execution rules are sent to UPF for data plane flow control and threshold control.

[0155] The Service Encapsulation Layer (SOP) user plane is used for user service data flow transmission and processing, including data packet routing, forwarding, monitoring and QoS processing, traffic statistics and reporting, etc. Its service data flow processing flow is shown in Figure 8:

[0156] When processing downlink data:

[0157] 1. UPF matches downlink data with Packet Detection Rules (PDRs) received from SMF to complete the mapping from SMF to QoS flow. If no match is found, the data packet is dropped.

[0158] 2. UPF adds the QoS flow identifier QFI to the header of the matched data packet according to the corresponding QoS execution rules.

[0159] 3. UPF performs rate control and threshold control on downlink data packets according to the corresponding QoS execution rules.

[0160] When processing upstream data:

[0161] 1. The UE matches the data packet to be sent with the flow description information of the QoS rule, thereby determining the QoS flow to which the service data belongs based on the matched QoS rule, and completing the mapping from SDF to QoS Flow. If no match is found, the data packet is discarded.

[0162] 2. The UE adds the QoS flow identifier QFI to the header of the matched data packets according to the QoS rule.

[0163] 3. The UE performs rate control on uplink data packets according to QoS rules.

[0164] 4. The UPF uses the PDR packet detection rules received from the SMF to verify the received uplink data, check whether the uplink data carries the correct QFI, and perform bitrate control on the received uplink data packets.

[0165] The Service Encapsulation Layer (SOP) information plane provides necessary information support for the control plane and user plane. Its main functions include mapping auxiliary service data flows (SDFs) to QoS flows, PDU session management, and determining QoS profiles, packet detection rules (PDRs), and QoS rules.

[0166] QoS status information used

[0167] Candidate QoS configuration status information

[0168] Business flow data requirements

[0169] The information plane exchanges information with the control plane and user plane. This information can be used by the control plane as a reference for QoS policy control, and by the user plane as a reference for mapping service data streams to QoS flows and rate control, etc. Taking the implementation of QoS control policies in the control plane as an example:

[0170] 1. The DAF module in the information plane will report QoS status, subsequent QoS configuration status, SDF requirement information, etc. to the PCF module in the control plane.

[0171] 2. The PCF module generates PCC rules based on the received information from the information plane and the application layer business requirements.

[0172] 3. Based on the generated PCC rules, guide the SMF to determine the corresponding QoS control rules.

[0173] Based on the functions of the aforementioned layers, the Service Encapsulation Layer (SOP) can decompose QoS requirements into different QoS profiles corresponding to different service types. As shown in Figure 9, these QoS profiles can be combined into hybrid QoS profiles to support mixed service types, such as communication-aware service QoS profiles, intelligent computing service QoS profiles, and communication-aware intelligent computing service QoS profiles. Besides focusing on overall network efficiency and value, this also allows various service domains to maintain a high degree of cohesion and low coupling.

[0174] Each type of service has its own specific QoS profile definition. For example, see Figure 10-13:

[0175] Based on their characteristics, perception business models focus on perception capability indicators such as accuracy and resolution in the perception domain. Some scenarios do not have high requirements for real-time performance and can be divided into two main categories: target localization and environmental detection.

[0176] Target localization-based sensing focuses on changes in the state of a specific target. Commonly used QoS profile metrics include:

[0177] (1) Detection performance: Indicators include false alarms, missed alarms, and detection probability;

[0178] (2) Accuracy: commonly used is absolute deviation or mean-square error (MSE).

[0179] (3) Resolution: The trade-off between system parameters and distance and velocity resolution is often characterized by fuzzy functions.

[0180] Environmental detection-type sensing focuses on overall information about the surrounding environment rather than individual targets, and the sensing results are often richer information such as images. Commonly used QoS profile metrics include:

[0181] (1) Spatial resolution, including three dimensions: distance resolution, azimuth resolution, and pitch resolution.

[0182] (2) Sidelobe performance: The total energy of a single pixel in radar imaging should come from a single spatial resolution unit.

[0183] (3) Image entropy describes the average amount of information in an image. The entropy value indicates the focus of each point in the image, thus characterizing the image quality; (4) Perception range describes the distance of the coverage area under the premise of specified perception performance.

[0184] (5) Perception probability, which describes the reliability of a specified perception.

[0185] The computing power business model focuses on computing power indicators such as computing speed and cache size in its computing domain and requires efficient utilization of computing power. Its computing power QoS profile object definition is shown in Figure 11, which includes computing resource utilization, computing speed, cache size, throughput, CPU utilization, MIPS and computing response time.

[0186] The QoS profile object definition of the digital twin service model is shown in Figure 12. It can be divided into three categories: network parameters, user perception, and object status. Specifically:

[0187] Network parameters include latency, throughput, connection success rate, coverage, packet loss rate, handover success rate, latency jitter, and acceptable bit error rate for each network unit.

[0188] User perception includes user experience model parameters (timeliness, session quality, accessibility, maintainability, integrity, content quality, usability), the five senses of the user (hearing, sight, touch, smell, taste), and emotion model parameters (joy, trust, fear, surprise, sadness, disgust, anger, and expectation), etc.

[0189] User / object state knowledge includes parameters of human vital signs model (heart rate, pulse, blood pressure, respiration, pain, blood oxygen, pupil and corneal reflex), 3D object model parameters, etc.

[0190] AI service QoS in an AI business model refers to the quality indicators of AI service performance, availability, and security, including inference speed, energy consumption, computational security, data privacy, and model controllability. Its QoS profile object definition is shown in Figure 13, which is divided into AI model and AI data. The indicators of AI model include inference accuracy, training or inference latency, training or inference data density, and training or inference energy efficiency; the indicators of AI data include data integrity, data redundancy, data timeliness, and data distribution.

[0191] Functional Protocol Layer (FOP):

[0192] The control plane of the Functional Protocol Layer (FOP) is used for configuration and control between objects, the user plane is used for carrying user service information flow transmission, and the information plane is used to provide necessary auxiliary information for the control plane and the user plane. The framework structure of the FOP is shown in Figure 14, and the protocol stacks of each plane are shown in Figures 15-17.

[0193] The Functional Protocol Layer (FOP) comprises the L1 Physical Sublayer (PHY), the L2 Link Sublayer, and the L3 Logical Sublayer. The L1 Physical Sublayer (PHY) is used for multiple access, providing physical channels, modulation and demodulation, channel coding and decoding, physical layer procedures, physical layer measurements, and interference mitigation. As shown in Figure 18, the physical channels include the dynamically variable Physical Dedicated Channel (PxDCH) (x: UL / DL / SL), the Physical Broadcast Channel (PBCH), the Physical Random Access Channel (PRACH), the Physical Shared Channel (PxSCH) (x: UL / DL / SL), and the Physical Control Channel (PxCCH) (x: UL / DL / SL).

[0194] PxDCH is a variable self-contained dedicated physical channel used for resource-exclusive transmission of services or UEs. It can simultaneously carry multiple modes of information, such as AI signal processing wireless transmission mode and latency deterministic and reliability-sensitive wireless transmission mode.

[0195] PxDCH is a self-contained physical channel that simultaneously transmits control information (CCE), demodulation reference signal (DMRS), and model / data information. The CCE carries information such as DMRS distribution changes, data PRB / RE resource changes, and MCS adjustments. If these related information remains unchanged, the CCE only carries a "no update indication" message. PxDCH is a structurally variable physical channel that can adapt to transmission scenarios such as ULBC (ultra-reliable low-latency broadband communication) and mULC (massive ultra-reliable low-latency communication) through dynamic matching of channel structure with wireless transmission modes.

[0196] The PxDCH channel supports radio resource partitioning transmission differentiated by radio transmission mode: For AI mode signal processing, the PxDCH can carry AI / neural network model update information or neuron information to assist data signal processing. This information is transmitted simultaneously with the data signal in the PxDCH. More than one radio transmission mode exists.<CCE, RS,AImodel(optional) / data> In the case of combinations, the channel adopts a channel structure of radio resource partitioning depending on the combination of radio transmission modes;<CCE, RSx,AImodel> ;<CCE, RSy, data> In the combination, if AI model information exists, this part can adopt a different MCS coding and modulation scheme than the data part, depending on the reliability requirements. Transmitted in PxDCH<CCE, RSx,AImodel> and<CCE, RSy, data> It has independent radio resource partitions and their own CCE configurations, RS time-frequency resource density configurations, and AImodel, data with different MCS coding and modulation schemes.

[0197] For wireless transmission modes sensitive to time delay determinism and reliability<CCE, RS, data> PxDCH can enable DSSS spread spectrum signal processing, and its corresponding DMRS demodulation reference signal can dynamically support high-density time and frequency resource configuration.

[0198] The Physical Shared Channel (PxSCH) is used for channel-sharing transmission of multi-service and multi-UE data.

[0199] For a certain service, one or a combination of PxSCH and PxDCH channels can be used for wireless transmission of service data.

[0200] The rules for enabling the PxDCH dedicated physical channel are as follows:

[0201] Step 1: Determine the logical priority of the QoS profile and service data transmission status monitoring information of the logical sublayer foundation QoS flow, and map it to LCID;

[0202] Step 2: The link sublayer determines the link priority based on the LCID priority (UL / DL / SL) and link monitoring information, and maps it to the corresponding transmission channel TCID;

[0203] Step 3: The physical sublayer determines the corresponding physical channel based on the TCID selected by the link sublayer and the mapping relationship between the TCID and the physical channel. TCIDs within a specified range are mapped to dedicated PxDCH physical channels for data transmission.

[0204] During business processing, the physical sublayer's built-in AI Agent and ROM's AI Engine provide auxiliary processing based on their functions and business requirements. The specific process is shown in Figure 19. The ROM's AI Engine obtains the corresponding AI inference model through training. When processing business, the FOP physical sublayer extracts relevant data and computational requirements from the AI / neural network, pushes this data to the AI ​​Engine training module for training, and pushes the new AI inference model to the inference module. The FOP physical sublayer sends the data and parameters to be processed to the AI ​​Engine inference module to obtain the results, which are then returned to the FOP physical sublayer for further processing. This method can be viewed as a form of object call between entities. By calling the ROM layer's AI Engine module resources, the FOP physical sublayer implements the relevant computational business of AI / neural networks, assisting the physical sublayer's digital signal processing algorithm in improving processing speed and accuracy.

[0205] The L2 link sublayer, including the Media Access Control (MAC) sublayer, is used for segmenting and reassembling Service Data Units (SDUs), mapping logical channels to transport channels, multiplexing and demultiplexing several logical channel SDUs with a transport block (TB), user equipment scheduling, resource allocation, link adaptation and power control, HARQ error correction, logical channel priority sorting and processing, and user equipment data priority processing.

[0206] The L3 logical sublayer includes the Radio Control Sublayer (RRC), Service Data Adaptation Sublayer (SDA), Packet Data Convergence Protocol Sublayer (PDCP), and Radio Link Control Sublayer (RLC). The L3 logical sublayer control plane is responsible for the signaling flow functions of the UE's radio configuration. The user plane is responsible for mapping service data to QoS, mapping QoS to data radio bearers or signaling radio bearers (DRB / SRB), service data flow control and transmission, deterministic transmission control, unified packet processing of network control signaling and user data, and data interaction with the L2 link sublayer through logical channels. The logical sublayer performs priority weighting scoring based on various dimensions of the service QoS Profile and QoS flow transmission status information to obtain the corresponding logical sublayer priority score. This logical sublayer priority score is mapped to a corresponding LCID value. The logical channel number (LCID) is used as input information for the link sublayer to determine scheduling priorities.

[0207] The Service Data Adaptator (SDA) sublayer includes the following two functional units:

[0208] Time Sensitive Controller (TSC): This latency-sensitive control function determines the logical sub-layer priority of services by real-time monitoring of QoS flow transmission status and its QoS Profile. This priority is then mapped to LCID and further used by the link layer to determine service scheduling priorities. This provides low-latency, low-jitter, and highly reliable communication services for data transmission. Through the TSC latency-sensitive control at the logical sub-layer, combined with the real-time guarantee of wireless scheduling at the link sub-layer and the low-latency frame structure waveform design at the physical sub-layer, a comprehensive, fully intrinsic deterministic support system for low latency and jitter is formed.

[0209] QoS Flow Handling (QFH): Implements the mapping between QoS Flow and DRB, and marks QoS Flow IDs for UL and DL packets.

[0210] The functional entities / instances (including UL / DL / SL, etc.) of the Functional Protocol Layer (FOP) primarily process services through interfaces such as QoS flow, Radio Bearer (DRB), RLC Channel, and Logical Channel (QoS specific). Information plane data is aggregated at the logical layer or used to provide auxiliary information for scheduling decisions at the link layer, as needed. Protocol processing distinguishes between logical channel IDs and types. Taking location awareness as an example, UE-specific location information is mapped to a UE-level LCID. Public location information is mapped to a public LCID. UE group shared location information is mapped to a UE group LCID. As an example, the uplink and downlink protocol stack architecture of the FOP is shown in Figures 20 and 21.

[0211] In the network system of this embodiment, it is possible to realize the function object call of heterogeneous entities / network elements. For example, the service object of network element A calls the function object of network element B. For the AI ​​service case, the AI ​​service object of network element A can call the Sidelink AI entity / instance object of B through its DL function protocol layer to provide function protocol layer services to others.

[0212] During service data transmission, the Functional Protocol Layer (FOP) can bypass one or more sublayers of PDCP, RLC, and MAC, or bypass some functional units of SDA, based on the dynamic QoS requirements of the service data, as shown in Figures 22 and 23. Based on service requirements, the RLC sublayer of the FOP layer is bypassed during uplink and downlink processes.

[0213] Taking the bypassing of the RLC sublayer as an example, the specific bypassing process is shown in Figure 24. The UPF functional unit of the SOP service encapsulation layer sends the service flow type indication and transmission status information notification to the service data adaptation sublayer SDA in the logical sublayer of the FOP service protocol layer. Its TSC functional unit triggers the latency-sensitive QoS Flow monitoring and control mechanism according to service requirements, and determines the QoS Flow that needs to be bypassed at the protocol layer and the bypassed sublayer. At this time, the bypassing time can be notified to the UE via RRC message or MAC CE according to the pre-set communication mechanism.

[0214] When notification is selected via RRC message, SDA returns the configuration for triggering UE protocol layer bypass to RRC. RRC then notifies the UE of the protocol layer bypass activation time via RRC message based on the configuration. Simultaneously, SDA transmits the protocol layer bypass trigger indication to PDCP. PDCP instructs RLC to be bypassed and exchanges relevant logical channel information with RLC. After taking over the logical channel, PDCP directly connects to MAC data processing.

[0215] When MAC CE notification is selected, SDA first conveys the protocol layer bypass trigger indication to PDCP. PDCP instructs RLC to be bypassed and exchanges relevant logical channel information with RLC. After PDCP takes over the logical channel, it connects to MAC, and MAC notifies UE of the timing of the protocol layer bypass effect through MAC CE.

[0216] After the bypass mechanism is triggered, the DL PDU is directly transmitted from the PDCP to the MAC, and a MAC header is added to indicate the protocol layer that the data packet needs to be bypassed. After the MAC PDU is sent to the UE, the UE parses the MAC header, bypasses the RLC, and submits the PDU to the PDCP for PDU UL processing. The process is the same as that of PDU DL.

[0217] It should be noted that, as shown in Figures 25 and 26, when the RLC is bypassed, the MAC needs to take over its packet fragmentation and reassembly functions, and the same MAC PDU can accommodate bypassed PDUs (such as PDCP PDUs) or non-bypassed PDUs (such as RLC PDUs).

[0218] The Resource Modeling Layer (ROM) comprises a control plane, an execution plane, and an information plane. The control plane is used for real-time control of resource objects, responsible for resource model creation and management. The execution plane serves as the carrier of signal processing, acting as the entity to perform specific business operations, such as computational processing (CPU / DSP / ASIC HWA / GPU, etc., executing computational tasks), signal channels (including fronthaul, midhaul, and backhaul signal or data transmission carriers), data storage (temporary storage such as TCM, and data stored on disk / Flash / array), AI model inference (AI model, inference / training execution based on AI hardware platforms), and perception and detection (environmental (including electromagnetic environment) perception and detection based on the association and collaboration of sensor computing entities, wireless spectrum, and other objects). The information plane monitors the status of resource objects to assist the control and execution planes in making dynamic adjustments.

[0219] As shown in Figure 27, the Resource Modeling Layer ROM functional unit includes the RMOM functional unit responsible for the management and maintenance of resource model objects, the RORM functional unit responsible for the establishment, association, modification and maintenance of resource object relationships, the ROSCH functional unit responsible for real-time scheduling of resource objects, the RORU functional unit responsible for resource object routing, and the OSMON functional unit responsible for monitoring the status of resource objects.

[0220] The ROSCH functional unit schedules various resources in the resource modeling layer ROM based on business requirements, and exchanges object states with O-ORCH through the control plane service encapsulation layer FOP to update the information of each object in O-ORCH, thereby realizing the scheduling of various resources in the business model, channel model, and computing model. The cooperation relationship of each resource object is shown in Figure 28, and the scheduling process is shown in Figure 29.

[0221] The control plane RMOM performs initial object creation and management, and establishes an object relationship network. It then pushes these object relationships to the execution plane and information plane, while simultaneously sending object information to O-ORCH via FOP for updates. O-ORCH sends object orchestration and scheduling instructions to FOP based on business requirements. FOP then relays these instructions layer by layer to ROM, where ROSCH performs internal object scheduling. The control plane reports service objects to FOP, and FOP assists the ROM control plane in object invocation collaboration. RORU routes resource objects within ROM, and the information plane reports object status information to the control plane via OSMON.

[0222] Object Orchestration and Scheduling (O-ORCH) periodically updates the service status (service status of each object at each layer) reported by the Service Encapsulation Layer (SOP) of multiple network entities. Multiple network entities within an autonomous system share a single O-ORCH. O-ORCH manages and schedules one or more network entities based on business / service requirements. Driven by business needs, O-ORCH systematically arranges and organizes the Service Encapsulation Layer (SOP), Functional Protocol Layer (FOP), and Resource Modeling Layer (ROM), ultimately forming network services that meet business requirements through scheduling and control. O-ORCH decouples business processes from the logical network and the physical network through abstraction. Users define business requirements using the abstract language provided by object orchestration, and object orchestration automatically constructs the user's logical network based on these definitions. Through object orchestration and scheduling, network complexity can be effectively shielded from users, reducing service design and deployment time.

[0223] Figures 30 and 31 illustrate the end-to-end network orchestration instantiation process and the collaboration process with various functional layers of the Object Orchestration and Scheduling (O-ORCH) system, respectively. After receiving a deployment service request, O-ORCH decomposes it into different layers according to the service type requirements and coordinates with relevant sub-service objects, functional objects, and resource object managers to orchestrate and instantiate service objects in each sub-layer. The openness achieved through API interfaces in the O-ORCH object management orchestration entity decouples user entry points, end-to-end cross-layer orchestration and service management, and the underlying network and infrastructure.

[0224] The Network Virtual / Entity Management (N-VEM) is responsible for the management of network element nodes in the network, including the management of physical network elements and virtual network element nodes. The physical network elements are user equipment (UE) and network equipment nodes, and the virtual network element nodes are digital twins based on physical network elements. Multiple autonomous systems share one Network Virtual / Entity Management (N-VEM).

[0225] As shown in Figure 32, the Network Virtual / Entity Management (N-VEM) includes the Unstructured Data Storage Function Module (UDSF), the UE Radio Management Function (UCMF), the Billing Function Module (CHF), the Unified Data Management Function (UDM), and the Message Frame Adapter Function Module (MFAF).

[0226] The specific functions of each module are as follows:

[0227] Unstructured Data Storage Function (UDSF): Stores specific unstructured data, such as session IDs and state data used by AMF and SMF.

[0228] Unified Data Repository (UDR). Unified data repository functionality;

[0229] UDM stores and retrieves contracted data;

[0230] PCF storage and retrieval strategy data, storage and retrieval of structured services;

[0231] NEF application data (including Packet Flow Description (PFD) for application detection and AF request information for multiple UEs).

[0232] UE radio Capability Management Function (UCMF): Used to store field entries corresponding to the UE radio function ID assigned by the PLMN or manufacturer.

[0233] Equipment Identity Register (EIR) is a system for registering and identifying equipment.

[0234] The Billing Function (CHF) is responsible for accurately calculating and allocating the costs of various services and resources used by users.

[0235] Data Collection Coordination Function (DCCF): This function coordinates the collection of data from one or more consumer NFs based on data collection requests from those NFs.

[0236] Network Node Management (NNM): Used to manage network nodes

[0237] Digital Twin Network Management (DTNM): Used to manage digital twin network nodes.

[0238] Unified Data Management (UDM) functions include: generation of 6G AKA authentication credentials, user identifier processing (e.g., storage and management of each user's SUPI in a 5G system), support for unhiding privacy-protected user identifiers (SUCI), access authentication based on subscription data (e.g., roaming restrictions), NF registration management for UE services (e.g., AMF for UE storage services, SMF for UE PDU session storage services), support for service / session continuity (by maintaining ongoing session allocation in SMF / DNN), MT-SMS delivery support, lawful interception functionality (especially in outbound roaming scenarios where UDM is the sole point of contact for the LI), subscription management, and SMS management.

[0239] Messaging Framework Adaptor Function (MFAF): Enables services to interact with the messaging framework.

[0240] Based on the above-mentioned object-oriented network service support system, Figure 33 shows an overall processing flow for services such as intelligent computing and sensing. After the various levels, modules and units in the support system establish connections and are activated, the UE and DN build service connections. After the O-ORCH realizes the object scheduling and command within each functional layer, data streams are transmitted between layers.

[0241] The system provided in this embodiment adopts an object-oriented network design, integrating the concepts of serviceability and programmability into all aspects of network design, enabling full decoupling and flexible allocation of hardware and software resources. This design not only enhances network flexibility and reduces the cost of network upgrades, but also provides "plug-and-play" foundational network interfaces for various emerging application scenarios and vertical industries, greatly improving the network's adaptability and scalability.

[0242] Example 2:

[0243] The present invention also provides a support method based on the above-mentioned object-oriented network service support system, including network entity A and network entity B existing in the same autonomous domain, a certain functional layer (SOP or FOP) of entity A that processes a certain service, its service requirements and the service processing capabilities of each functional layer of entity A, determining the service support that needs to initiate a specific functional layer call to other entities and initiating the request to object orchestration and scheduling O-ORCH.

[0244] After receiving a business support request, the object orchestration and scheduling system makes an object allocation and scheduling decision based on the updated service status of entities A and B, and returns the allocation result to entity A.

[0245] After receiving the object allocation and scheduling decision, entity A updates and stores the capabilities of each functional layer of entity B, and at the same time initiates a request to entity B to call a specific functional layer; after receiving the scheduling request from entity A, the specific functional layer of entity B returns call confirmation information to entity A and establishes a service function connection with entity A, thereby completing the business support for the specific functional layer call.

[0246] The methods by which network entity A schedules the functional layer of network entity B include peer-to-peer calls and non-peer-to-peer calls. Peer-to-peer calls refer to network entity A's SOP or FOP scheduling the corresponding SOP or FOP resources of network entity B. Non-peer-to-peer calls refer to network entity A's SOP scheduling network entity B's FOP resources or network entity A's FOP scheduling network entity B's ROM resources. Figure 34 shows the peer-to-peer call service flow, and Figures 35 and 36 show the non-peer-to-peer call service flow.

[0247] The peer-to-peer and non-peer-to-peer calls initiated for business support meet certain rule conditions, among which:

[0248] The basic principles for service calls between peer layers include:

[0249] 1. Network element entities A and B negotiate service rules and service scope through peer-to-peer interlayer communication.

[0250] 2. Each peer layer, including the resource modeling layer, functional protocol layer, and service encapsulation layer, can negotiate service calls between the peer layers of entities A and B.

[0251] 3. Service calls between peer layers can be provided layer by layer, or the network element entity can be used as a whole for service calls. In this case, when entity A calls an object of B, it does not care about how B provides services internally, but only needs to make a service request. A does not need to care about B's processing of the service request.

[0252] The basic principles of service invocation in a non-peer layer include:

[0253] (1) Network element entities A and B negotiate service rules and service scope through non-peer inter-layer communication (inter-object communication).

[0254] (2) Service calls provided by the lower layer to the higher layer can be negotiated between the non-peer layers of entities A and B.

[0255] (3) Service calls between peer layers can be provided in layers or the network element entity can be used as a whole for service calls. In this case, when entity A calls B's object, it does not care how B provides services internally, but only needs to make a service request. A does not need to care about B's processing of the service request.

[0256] The multi-level object service invocation mode supports different entities, and instantiates the communication between UE and network, UE and UE, and network element and network element as communication between objects. The two parties in the communication construct a communication object tuple (e.g., UE1 object <---> UE2 object). Based on the invocation level, it is divided into peer-to-peer communication and non-peer-to-peer communication, realizing flexible resource management and scheduling.

[0257] Example 3:

[0258] Current 5G network services lack a credit authorization mechanism, relying on static pre-configuration by the management end. Users must complete the entire service activation process to activate services. This embodiment proposes a dynamic credit authorization mechanism, enabling real-time activation of user services or real-time authorization of object calls.

[0259] A third-party service authorization and guarantee credit method based on the above-mentioned object-oriented network service support system is shown in Figure 37. The specific method is as follows:

[0260] When an entity needs to initiate a service / business authorization request that it cannot decide on its own using O-ORCH, the object orchestration and scheduling entity forwards the service / business authorization request to the network virtual entity management entity. When the network virtual entity management entity cannot decide on its own, it sends a credit query to a trusted third party, which returns the query result based on its credit information. The network virtual entity management entity determines whether to authorize based on the query result and sends the result to the object orchestration and scheduling entity. The object orchestration and scheduling network element enables the services / businesses of each functional layer based on the determination result.

[0261] In this embodiment, the service authorization and guarantee trust mechanism is suitable for: new user service activation, and the management and permission of object calls between heterogeneous entities. The security engine is not merely a computing resource; it also includes a trusted third-party role. This role provides security guarantees when authentication processes such as security authentication fail between a UE and a base station XNB or core network element. Through this security guarantee mechanism, UEs can quickly access the network or quickly authenticate with it. When a UE needs to enable a new function or upgrade its QoS service level, and the network fails to promptly grant the corresponding service permission, temporary access can be achieved through the trusted security guarantee mechanism. This third-party guarantee mechanism requires the use of blockchain and AI large-scale models, with network nodes or external third parties possessing the necessary capabilities providing guarantees for the UE (or its service slices) or network elements.

[0262] The security parameters on the UE side include user credit score or level, root key, etc.

[0263] The third-party service authorization and guarantee credit method provided in this embodiment has the ability to perceive and intervene in related security and network layer risks:

[0264] The network needs to monitor the security status changes of all terminal devices across the network, anticipate in advance which terminals may face security risks, the level of security protection mechanisms they may need to activate, and their impact on the overall network business coordination, and thus activate backup service nodes in advance.

[0265] In addition, the security posture information of the UE terminal can be disseminated, in whole or in part, within or outside the autonomous system as needed, so that devices in the network can take proactive security precautions.

[0266] Example 4:

[0267] This embodiment provides an example of an AI business / service processing flow based on an endogenous intelligent agent (AI Agent) or an intelligent engine (AI Engine). The AI ​​Agent and AI Engine collaborate through object calls at various layers to support AI-type business / services. The AI ​​Engine consists of two parts: training and inference. The training part is not responsible for object management and creation; the function of providing object services to the upper layer is handled by the ROM inference part. Object creation and maintenance are the responsibility of the inference AI Engine.

[0268] As shown in Figure 38, the Service Encapsulation Layer (SOP) initiates an object call, and the Functional Protocol Layer (FOP) makes an object call to the Resource Layer's ROM Intelligent Engine (AI Engine) based on AI business / service requirements to realize model modeling and AI calculation functions. The result is then sent to the Functional Protocol Layer (FOP) to form the AI ​​business data processing result, and returned to the Functional Protocol Layer (FOP) to complete the business / service process.

[0269] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. An object-oriented network service support system, characterized in that, include: Service Encapsulation Layer (SOP), Functional Protocol Layer (FOP), Resource Modeling Layer (ROM), Object Orchestration and Scheduling (O-ORCH), and Network Virtual Entity Management (N-VEM); The Service Object Encapsulation Layer (SOP) includes a control plane, a user plane, and an information plane. The control plane, based on the service object, enables real-time control of business data flow to support various application services and manage user registration, authentication, and mobility. The user plane, based on service objects, enables the transmission and processing of business data streams; the information plane, also based on service objects, provides necessary auxiliary information for the control plane and user plane. The Functional Object Protocol (FOP) layer comprises a control plane, a user plane, and an information plane. The control plane, based on functional objects, enables configuration and control between objects. The user plane, also based on functional objects, enables the transmission and carrying of user service information flows. The information plane, based on functional objects, provides necessary auxiliary information for the control and user planes. The Resource Object Modeling Layer (ROM) comprises a control plane, an execution plane, and an information plane. The control plane, based on resource objects, enables real-time control of resource objects and is responsible for resource model creation and management. The execution plane, also based on resource objects, serves as the carrier for signal processing and acts as the execution object entity to perform specific business operations. The information plane, based on resource objects, monitors the status of resource objects to assist the control and execution planes in making dynamic adjustments. The object orchestration and scheduling O-ORCH periodically updates the service status (service status of each object in each layer) reported by the service encapsulation layer SOP of multiple network entities. Multiple network entities within an autonomous system share a single object orchestration and scheduling O-ORCH. The object orchestration and scheduling O-ORCH performs object management and scheduling on one or more network entities according to business / service requirements. The Network Virtual / Entity Management (N-VEM) is responsible for the management of network element nodes in the network, including the management of physical network elements and virtual network element nodes. The physical network elements are user equipment (UE) and network equipment nodes, and the virtual network element nodes are digital twins based on physical network elements. Multiple autonomous systems share one Network Virtual / Entity Management (N-VEM).

2. The object-oriented network service support system according to claim 1, characterized in that: The Service Encapsulation Layer (SOP) includes the Authentication Server Function Module (AUSF), Access and Mobility Management Function Module (AMF), Network Service Presentation Function Module (NEF), Network Storage Function Module (NRF), Network Slice Admission Control Function Module (NSACF), Network Slice Authentication and Authorization Function Module (NSSAAF), Network Slice Selection Function (NSSF), Policy Control Function Module (PCF), Session Management Function Module (SMF), Non-Seamless WLAN Offload Function Module (NSWOF), Edge Application Service Discovery Function Module (EASDF), Object Service Capability Management Module (OSCM), User Plane Function Module (UPF), and Data Analysis Function Module (DAF).

3. The object-oriented network service support system according to claim 1, characterized in that: The Functional Protocol Layer (FOP) includes The L1 physical sublayer PHY is used to utilize the resource objects (wireless resources, AI model resources) provided by the resource object modeling layer for multiple access, providing physical channels, modulation and demodulation, channel coding and decoding, physical layer processes, physical layer measurements and anti-interference processing. The L2 link sublayer, including the Media Access Control (MAC) sublayer, is used for segmentation and reassembly of Service Data Units (SDUs), mapping between logical channels and transport channels, multiplexing and demultiplexing of several logical channel SDUs and a transport block (TB), user equipment scheduling, resource allocation, link adaptation and power control, HARQ error correction, logical channel priority sorting and processing, and user equipment data priority processing. The L3 logical sublayer includes the Radio Resource Control (RRC) sublayer, the Service Data Adaptation (SDA) sublayer, the Packet Data Convergence Protocol (PDCP) sublayer, and the Radio Link Control (RLC) sublayer. The L3 logical sublayer control plane is responsible for the signaling flow functions of the UE's radio configuration; the user plane is responsible for the mapping of service data and QoS, the mapping of QoS and data radio bearers or signaling radio bearers DRB / SRB, service data flow control and transmission, deterministic transmission control, unified packet processing of network control signaling and user data, and interaction with the L2 link sublayer.

4. The object-oriented network service support system according to claim 3, characterized in that: During service data transmission, the Functional Protocol Layer (FOP) can dynamically bypass one or more sublayers of PDCP, RLC, and MAC, or bypass some functional units of SDA, based on the QoS requirements of the service data.

5. The object-oriented network service support system according to claim 3, characterized in that: The physical channels of the Functional Protocol Layer (FOP) include the dynamically variable physical dedicated channel PxDCH (x: UL / DL / SL), the physical broadcast channel PBCH, the physical random access channel PRACH, the physical shared channel PxSCH (x: UL / DL / SL), and the physical control channel PxCCH (x: UL / DL / SL).

6. The object-oriented network service support system according to claim 5, characterized in that: The Variable Physical Dedicated Channel (PxDCH) is a self-contained dedicated physical channel with a variable structure, used for resource-exclusive transmission of services or UEs; the Variable Physical Dedicated Channel (PxDCH) simultaneously transmits control information (CCE), demodulation reference signal (DMRS), and model / data information.

7. The object-oriented network service support system according to claim 1, characterized in that: The resource modeling layer ROM includes an RMOM functional unit responsible for the management and maintenance of resource model objects, a RORM functional unit responsible for the establishment, association, modification and maintenance of resource object relationships, a ROSCH functional unit responsible for real-time scheduling of resource objects, a RORU functional unit responsible for resource object routing, and an OSMON functional unit responsible for monitoring the status of resource objects.

8. The object-oriented network service support system of claim 7, wherein: The ROSCH functional unit implements internal object scheduling of the control plane, execution plane, and information plane based on the O-ORCH object orchestration and scheduling instructions.

9. The object-oriented network operations support system of claim 1, wherein: The object orchestration and scheduling (O-ORCH) includes an object service authorization management (OSAU) module that manages the configuration of external service licenses for managed objects; an object allocation and recycling (OARE) module that allocates and reclaims objects at each layer of an entity based on object status and service requirements; and an object status management (OSM) module that is responsible for collecting, updating, and recording object status and capability information.

10. The object-oriented network operations support system of claim 1, wherein: The Network Virtual / Entity Management (N-VEM) includes an Unstructured Data Storage Function Module (UDSF), a UE Radio Management Function (UCMF), a Billing Function Module (CHF), a Unified Data Management Function Module (UDM), a Message Frame Adapter Function Module (MFAF), and a Digital Virtual / Twin Network Management (DVNM).

11. The object-oriented network operations support system of claim 1, wherein: The Service Object Encapsulation Layer (SOP), Functional Object Protocol Layer (FOP), Object Orchestration and Scheduling (O-ORCH), and Network Virtual / Entity Management (N-VEM) all have an endogenous intelligent agent (AI Agent) responsible for the process and logic control of AI services and their own network intelligence. The Resource Object Modeling Layer (ROM) has an intelligent engine (AI Engine) responsible for providing AI model resources and inference / training computing resources. The endogenous intelligent agent (AI Agent) and the intelligent engine (AI Engine) collaborate through object calls at each layer to support AI-type services.

12. A service support method based on the object-oriented network service support system according to claims 1-11, characterized in that: This includes network entities A and B existing within the same autonomous system, the service requirements of a certain functional layer (SOP or FOP) of entity A that processes a certain service, and the service processing capabilities of each functional layer of entity A. It determines the service support that needs to initiate a specific functional layer call to other entities and initiates the request to the object orchestration and scheduling module O-ORCH. After receiving a business support request, the object orchestration and scheduling system makes an object allocation and scheduling decision based on the updated service status of entities A and B, and returns the allocation result to entity A. After receiving the object allocation and scheduling decision, entity A updates and stores the capabilities of each functional layer of entity B, and at the same time initiates a request to entity B to call a specific functional layer; after receiving the scheduling request from entity A, the specific functional layer of entity B returns call confirmation information to entity A and establishes a service function connection with entity A, thereby completing the business support for the specific functional layer call.

13. The business support method of claim 12, wherein: The method by which network entity A schedules functional layer objects of network entity B includes peer-to-peer calls and non-peer-to-peer calls; the peer-to-peer call refers to network entity A's SOP or FOP scheduling the corresponding SOP or FOP resources of network entity B; the non-peer-to-peer call refers to network entity A's SOP scheduling the FOP resources of network entity B or network entity A's FOP scheduling the ROM resources of network entity B.

14. A method for third-party service authorization and guarantee credit granting based on the object-oriented network service support system described in claims 1-11, characterized in that: When an entity needs to initiate a service / business authorization request that it cannot decide on its own using O-ORCH, the object orchestration and scheduling entity will forward the service / business authorization request to the network virtual entity management entity. When the network virtual entity management entity cannot decide on its own, it will send a credit query to a trusted third party, and the trusted third party will return the query result based on its credit information. The network virtual entity management judges whether to authorize according to the query result, and sends the result to the object arrangement and scheduling entity, and the object arrangement and scheduling network element issues an instruction of whether to permit service / service to each function layer according to the judgment result.

Images