Synchronization of multiple data streams

Abstract

A first network function (NF) receives parameters indicating a request for synchronization of a plurality of data flows. The first NF sends, based on the parameters, a user plane rule to a second NF indicating the second NF to perform synchronized forwarding of packets of the plurality of data flows.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 058,815, filed July 30, 2020, the entire contents of which are incorporated herein by reference. Attached Figure Description

[0003] Examples of several embodiments of the various implementations of the invention are described herein with reference to the figures.

[0004] Figure 1 A diagram illustrating an example 5G system architecture according to an embodiment of this disclosure.

[0005] Figure 2 A diagram illustrating an example 5G system architecture according to an embodiment of this disclosure.

[0006] Figure 3 This is a system diagram of an example wireless device and network node in a 5G system according to an embodiment of the present disclosure.

[0007] Figure 4 A system diagram of an example wireless device according to an embodiment of this disclosure.

[0008] Figure 5A and Figure 5B Two registration management status models in UE 100 and AMF 155 are described, representing aspects of the embodiments according to this disclosure.

[0009] Figure 6A and Figure 6B Two connection management state models in UE 100 and AMF 155 are described, representing aspects of the embodiments according to this disclosure.

[0010] Figure 7 A graph for classifying and labeling traffic according to an embodiment of this disclosure.

[0011] Figure 8 This is an exemplary call flow for a registration procedure according to an embodiment of the present disclosure.

[0012] Figure 9 This is an exemplary call flow for a registration procedure according to an embodiment of the present disclosure.

[0013] Figure 10 This is an exemplary call flow for a service request procedure according to an embodiment of the present disclosure.

[0014] Figure 11 This is an exemplary call flow for a service request procedure according to an embodiment of the present disclosure.

[0015] Figure 12 An exemplary call flow for establishing a PDU session according to an embodiment of the present disclosure.

[0016] Figure 13 An exemplary call flow for establishing a PDU session according to an embodiment of the present disclosure.

[0017] Figure 14 An example of an exemplary mobile communication network according to an embodiment of the present disclosure is shown.

[0018] Figure 15 A diagram illustrating an example 5G strategy and charging control system architecture according to an embodiment of this disclosure.

[0019] Figure 16 Example call flow for establishing a charged PDU session according to an embodiment of this disclosure.

[0020] Figure 17 A diagram illustrating an exemplary communication system architecture according to an embodiment of this disclosure.

[0021] Figure 18 An exemplary mobile communication network supporting the synchronization of multiple service data streams is shown according to aspects of embodiments of the present disclosure.

[0022] Figure 19 An exemplary mobile communication network supporting the synchronization of multiple service data streams is illustrated according to aspects of embodiments of the present disclosure.

[0023] Figure 20 This is an exemplary invocation process for an aspect of an implementation according to this disclosure.

[0024] Figure 21 An exemplary diagram illustrating a service data session establishment request message body according to an embodiment of this disclosure.

[0025] Figure 22 An exemplary diagram is provided to depict a procedure of a UE according to an embodiment of this disclosure.

[0026] Figure 23 An exemplary diagram illustrating a procedure for a first network function of an embodiment according to this disclosure.

[0027] Figure 24 An exemplary diagram illustrating a procedure for a second network function according to an embodiment of the present disclosure.

[0028] Figure 25 This is an exemplary invocation process for an aspect of an implementation according to this disclosure.

[0029] Figure 26 This is an exemplary invocation process for an aspect of an implementation according to this disclosure.

[0030] Figure 27A and Figure 27B A base station is described that performs synchronization of multiple service data streams according to an embodiment of the present disclosure.

[0031] Figure 28A and Figure 28B User plane functionality for synchronizing multiple service data streams according to an embodiment of this disclosure is described.

[0032] Figure 29 An exemplary 5G mobile communication network supporting the synchronization of multiple service data streams is illustrated according to aspects of embodiments of the present disclosure.

[0033] Figure 30 An exemplary 5G mobile communication network supporting the synchronization of multiple service data streams is illustrated according to aspects of embodiments of the present disclosure.

[0034] Figure 31 This is an exemplary invocation process for an aspect of an implementation according to this disclosure.

[0035] Figure 32 Example call diagrams for aspects of embodiments according to this disclosure.

[0036] Figure 33 This is an exemplary invocation process for an aspect of an implementation according to this disclosure. Detailed Implementation

[0037] Exemplary embodiments of the present invention enable the implementation of enhanced features and functions in 5G systems. Exemplary embodiments of the present invention enable the implementation of enhanced features and functions in 6G systems or future communication systems. More specifically, embodiments of the techniques disclosed herein may involve the synchronization of multiple service data streams (e.g., for 5G or future communication systems). Throughout this disclosure, UEs, wireless devices, terminals, and mobile devices are interchangeable. Throughout this disclosure, base stations, (radio)access networks ((R)ANs), next-generation radio access networks (NG-RANs), new radio node Bs (gNBs), and next-generation eNodeBs (ng-eNBs) are interchangeable. Throughout this disclosure, base stations, radio access networks (RANs), and eNodeBs are interchangeable.

[0038] Throughout this disclosure, FNF, SNF, CHF, AMF, SMF, UPF, PCF, UDM, OAM, and AF are exemplary network functions that can be implemented as network elements on dedicated hardware and / or as... Figure 4The network nodes shown are either implemented as software instances running on (dedicated) hardware and / or shared hardware, or as virtualization functions instantiated on a suitable platform.

[0039] The following abbreviations are used throughout this disclosure:

[0040] 5G (Fifth Generation Mobile Network)

[0041] 5GC 5G Core Network

[0042] 5GS 5G system

[0043] 5G-AN 5G Access Network

[0044] 5QI 5G QoS Indicator

[0045] ACK confirmation

[0046] AF application functions

[0047] A-GNSS Auxiliary GNSS

[0048] AMBR Aggregation Maximum Bit Rate

[0049] AMF Access and Mobility Management Functions

[0050] AN access network

[0051] ANDSP Access Network Discovery and Selection Policy

[0052] APN (Access Point Name)

[0053] ARP allocation and retention priority

[0054] BD Billing Domain

[0055] BPS barometric pressure sensor

[0056] CCNF Public Control Network Functions

[0057] CDR Fee Data Records

[0058] CHF Paid Features

[0059] CIoT Cellular IoT

[0060] CN Core Network

[0061] CP control plane

[0062] C-V2X Cellular Vehicle Connectivity

[0063] DAB Digital Audio Broadcasting

[0064] DDN Downlink Data Notification

[0065] DDoS (Distributed Denial of Service)

[0066] DL downlink

[0067] DN Data Network

[0068] DN-AAA Data Network Authentication Authorization and Accounting

[0069] DNN Data Network Name

[0070] DTMB Digital Terrestrial Multimedia Broadcasting

[0071] ECGI E-UTRAN Cell Global Identifier

[0072] ECID Enhanced Cell Identification

[0073] E-CSCF Emergency Call Session Control Function

[0074] eNodeB Evolution Node B

[0075] EPS Evolution Package System

[0076] E-UTRAN Evolution Universal Terrestrial Radio Access Network

[0077] FDD (Frequency Division Duplex)

[0078] FNF First Network Function

[0079] Fully Qualified Domain Name (FQDN)

[0080] F-TEID Fully Qualified TEID

[0081] GAD Geographic Region Description

[0082] GMLC Gateway Mobile Location Center

[0083] gNB Next Generation Node B

[0084] gNB-CU-CP gNB Central Unit Control Plane

[0085] GNSS Global Navigation Satellite System

[0086] GPSI General Public Subscription Identifier

[0087] GTP GPRS Tunneling Protocol

[0088] GUTI (Globally Unique Temporary Identifier)

[0089] GW gateway

[0090] HGMLC Homepage GMLC

[0091] HTTP (Hypertext Transfer Protocol)

[0092] ID identifier

[0093] IMEI (International Mobile Equipment Identity)

[0094] IMEI DB (IMEI Database)

[0095] IMS IP Multimedia Subsystem

[0096] IMSI International Mobile Subscriber Identity

[0097] IP Internet Protocol

[0098] IP-CAN IP connection access network

[0099] Layer 2 (Data Link Layer)

[0100] Layer 3 (Network Layer)

[0101] LADN Local Area Network Data Network

[0102] LAN (Local Area Network)

[0103] LCS Location Service

[0104] LI legitimate interception

[0105] LMC Location Management Component

[0106] LMF location management function

[0107] LPP LTE positioning protocol

[0108] LRF orientation search function

[0109] MAC Media Access Control

[0110] MEI (Mobile Equipment Identifier)

[0111] MIB Master Information Block

[0112] MICO only initiates connections via mobile.

[0113] MME (Mobility Management Entity)

[0114] MO (Mobile Origin)

[0115] MO-LR Mobile Origin Location Request

[0116] MSISDN Mobile Subscriber ISDN

[0117] MT movement terminated

[0118] MT-LR Mobile Termination Location Request

[0119] N3IWF Non-3GPP Interoperability Function

[0120] NAI Network Access Identifier

[0121] NAS Non-Access Layer

[0122] NAT (Network Address Translation)

[0123] NB-IoT Narrowband IoT

[0124] NCGI NR cell global identifier

[0125] NEF Network Exposure Function

[0126] NF Network Functions

[0127] NGAP Next Generation Application Protocol

[0128] ng-eNB Next-generation eNB

[0129] NG-RAN NR Radio Access Network

[0130] NI-LR Network-Induced Localization Request

[0131] NR New Radio

[0132] NRF Network Storage Function

[0133] NRPPa New Radio Positioning Protocol A

[0134] NSI Network Slicing Example

[0135] NSSAI Network Slice Selection Auxiliary Information

[0136] NSSF Network Slice Selection Function

[0137] NWDAF Network Data Analysis Function

[0138] OAM Operations Management and Maintenance

[0139] OCS Online Payment System

[0140] OFCS Offline Billing System

[0141] OTDOA Observation Time Difference

[0142] PCC Policy and Fee Control

[0143] PCF policy control function

[0144] PCRF policy and charging rule functions

[0145] PDN packet data network

[0146] PDU Protocol Data Unit

[0147] PEI Permanent Device Identifier

[0148] PGW PDN Gateway

[0149] PLMN Public Land Mobile Network

[0150] ProSe based on proximity services

[0151] QFI QoS Flow Identifier

[0152] QoS (Quality of Service)

[0153] RM Registration Management

[0154] RA Random Access

[0155] RAN (Radio Access Network)

[0156] RAT Radio Access Technology

[0157] RRC Radio Resource Control

[0158] RM Registration Management

[0159] S1-AP S1 Application Protocol

[0160] SBA Service-Based Architecture

[0161] SCM Security Context Management

[0162] SEA Safety Anchor Function

[0163] SET SUPL Enable Terminal

[0164] SGW Service Gateway

[0165] SIB System Information Block

[0166] SLP SUPL Positioning Platform

[0167] SM Session Management

[0168] SMF Session Management Function

[0169] SMSF SMS Function

[0170] SNF Second Network Function

[0171] S-NSSAI Single Network Slice Selection Auxiliary Information

[0172] SS synchronization signal

[0173] SSC Session and Service Continuity

[0174] SUCI Service User Relevance ID

[0175] SUPI subscriber permanent identifier

[0176] SUPL Safety User Plane Position

[0177] TA tracking area

[0178] TAI Tracking Area Identifier

[0179] TBS Ground Beacon System

[0180] TCP Transmission Control Protocol

[0181] TEID (Tunnel Endpoint Identifier)

[0182] TMSI Temporary Mobile Subscriber Identity

[0183] TNAN Trusted Non-3GPP Access Network

[0184] TNGF Trusted Non-3GPP Gateway

[0185] TRP Transmit and Receive Points

[0186] UCMF UE Radio Capability Management Function

[0187] UDR Unified Data Storage

[0188] UDM Unified Data Management

[0189] UDP User Datagram Protocol

[0190] UE User Equipment

[0191] UL uplink

[0192] UL CL Uplink Classifier

[0193] UPF User Plane Functions

[0194] V2X vehicle-to-everything (V2X)

[0195] WLAN (Wireless Local Area Network)

[0196] XML (Extensible Markup Language)

[0197] Example Figure 1 and Figure 2A 5G system including an access network and a 5G core network is depicted. An example 5G access network may include an access network connected to the 5G core network. The access network may include NG-RAN 105 and / or non-3GPP AN 165. An example 5G core network may connect to one or more 5G access networks, 5G-AN and / or NG-RAN. The 5G core network may include, as shown in the example... Figure 1 and examples Figure 2 The functional elements or network functions in the system, wherein the interface can be used for communication between functional elements and / or network elements.

[0198] In the example, a network function can be a processing function within a network, which may have functional behaviors and / or interfaces. Network functions can be implemented as network elements on dedicated hardware and / or such as... Figure 3 and Figure 4 The network nodes depicted are either implemented as software instances running on dedicated hardware and / or shared hardware, or as virtual functions instantiated on a suitable platform.

[0199] In the example, the Access and Mobility Management (AMF) 155 may include the following functions (some of the functions of AMF 155 may be supported in a single instance of AMF 155): termination of the RAN 105CP interface (N2), termination of NAS (N1), NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF155 events and interfaces with the LI system), providing transport for session management, SM messages between UE 100 and SMF 160, transparent proxy for routing SM messages, access authentication, access authorization, providing transport for SMS messages between UE 100 and SMSF, security anchor function, SEA, interaction with AMFF 150 and UE 100, receiving intermediate keys established as a result of the UE 100 authentication process, receiving security context management (SCM) keys from the SEA for deriving access network-specific keys, etc.

[0200] In the example, AMF 155 can support non-3GPP access networks through the N2 interface with N3IWF 170, support NAS signaling with UE 100 through N3IWF 170, support authentication, mobility management, and separate security context states for UE 100 connected via non-3GPP access 165 or simultaneously via 3GPP access 105 and non-3GPP access 165, support effective coordination of RM contexts via 3GPP access 105 and non-3GPP access 165, support CM management context for UE 100 for connectivity via non-3GPP access, and so on.

[0201] In the example, an AMF 155 area may include one or more AMF 155 sets. An AMF 155 set may include some AMF 155s serving a given area and / or network slice. In the example, multiple AMF 155 sets may be each AMF 155 area and / or network slice. An application identifier may be an identifier that can be mapped to a specific application traffic detection rule. A configured NSSAI may be an NSSAI that can be provided in UE 100. For DNN, the DN 115 Access Identifier (DNAI) may be an identifier for user plane access to DN 115. Initial registration may be related to UE 100 registration in RM-DEREGISTERED (RM-Deregister) 500, 520 states. An N2AP UE 100 association may be a logical association between a 5G AN node and an AMF 155 based on UE 100. An N2AP UE-TNLA combination may be a combination between an N2AP UE 100 association and a TNL association for a specific transport network layer, for a given UE 100.

[0202] In the example, the session management function SMF 160 may include one or more of the following functions (one or more of the SMF 160 functions may be supported in a single instance of SMF 160): session management (e.g., session establishment, modification, and release, including tunnel maintenance between UPF 110 and AN 105 nodes), UE 100 IP address allocation and management (including optional authorization), selection and control of UP functions, configuring traffic redirection at UPF 110 to route traffic to the appropriate destination, terminating the interface for policy control functions, controlling policy enforcement and a portion of QoS, lawful interception (for SM events and interfaces with LI systems), terminating the SM portion of NAS messages, downlink data notification, initiating AN-specific SM information, sending it to (R)AN 105 via N2 through AMF155, determining the SSC mode of the session, roaming functions, handling local execution to apply QoS SLA (VPLMN), charge data collection and charge interface (VPLMN), lawful interception (in VPLMN, for SM events and interfaces with LI systems), and support for external DN. The interaction of DN 115 is used to transmit signaling for PDU session authorization / authentication by external DN 115, etc.

[0203] In the example, the User Plane Function UPF 110 may include one or more of the following functions (some of the UPF 110 functions may be supported in a single instance of UPF 110): anchor points for movement within / between RATs (if applicable), external PDU session points interconnected to DN115, packet routing and forwarding, packet inspection and user plane portion of policy rule enforcement, lawful interception (UP collection), traffic usage reporting, uplink classifier for routed traffic flows supporting data networks, branch points for multihomed PDU sessions, QoS processing in the user plane, uplink traffic authentication (SDF to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering, downlink data notification triggering, etc.

[0204] In the example, UE 100 IP address management may include the allocation and release of UE 100 IP addresses and / or the updating of allocated IP addresses. UE 100 may set the requested PDU type during the PDU session establishment procedure based on its IP stack capabilities and / or configuration. In the example, SMF 160 may select the PDU type for the PDU session. In the example, if SMF 160 receives a request to set the PDU type to IP, SMF 160 may select the PDU type as IPv4 or IPv6 based on DNN configuration and / or operator policies. In the example, SMF 160 may provide a reason value to UE 100 to indicate whether other IP versions are supported on the DNN. In the example, if SMF 160 receives a request for the PDU type to be IPv4 or IPv6, and the requested IP version is supported by the DNN, SMF 160 may select the requested PDU type.

[0205] In an exemplary implementation, the 5GC element and UE 100 may support the following mechanism: During the PDU session establishment procedure, the SMF 160 may send an IP address to the UE 100 via SM NAS signaling. Once the PDU session can be established, IPv4 address allocation and / or IPv4 parameter configuration can be used via DHCPv4. If IPv6 is supported, IPv6 prefix allocation can be supported via stateless IPv6 autoconfiguration. In the example, the 5GC network element may support IPv6 parameter configuration via stateless DHCPv6.

[0206] 5GC can support the allocation of static IPv4 addresses and / or static IPv6 prefixes based on subscription information in UDM 140 and / or on configurations on a per subscriber, per DNN basis.

[0207] The User Plane Function (UPF 110) can handle the user plane path of PDU sessions. The UPF 110, which provides an interface to the data network, can support the function of PDU session anchoring.

[0208] In the example, the policy control function PCF 135 can support a unified policy framework to control network behavior, provide policy rules for control plane functions to enforce policy rules, implement a front-end for accessing subscription information related to policy decisions in the User Data Repository (UDR), and so on.

[0209] The Network Exposure Function (NEF 125) can provide a means to securely expose services and capabilities provided by 3GPP network functions, switch between information exchanged with AF 145 and information exchanged with internal network functions, receive information from other network functions, and so on.

[0210] In one example, the Network Repository Function (NRF) 130 can support service discovery functions that can receive NF discovery requests from NF instances, provide NF instances with information about discovered NF instances (to be discovered), and maintain information about available NF instances and the services they support, etc.

[0211] In one example, NSSF 120 can select a set of network slice instances serving UE 100 to determine the allowed NSSAI. In this example, NSSF 120 can determine the set of AMF 155 to be used to serve UE 100, and / or determine the list of candidate AMF 155s by querying NRF 130 based on configuration.

[0212] In the example, the data stored in the UDR may include at least user subscription data, including at least subscription identifiers, security credentials, access and mobility-related subscription data, session-related subscription data, policy data, and so on.

[0213] In one example, the AUSF 150 can support authentication server functionality (AUSF 150).

[0214] In one example, application function AF 145 can interact with the 3GPP core network to provide services. In another example, based on operator deployment, application functions can be trusted by the operator to interact directly with the relevant network functions. Application functions that the operator does not allow to directly access network functions can interact with the relevant network functions using an external exposure framework (e.g., via NEF 125).

[0215] In the example, the control plane interface between (R)AN 105 and the 5G core can support connecting various types of ANs (e.g., 3GPP RAN 105, N3IWF 170 for untrusted access 165) to the 5GC via control plane protocols. In the example, the N2 AP protocol can be used for both 3GPP access 105 and non-3GPP access 165. In the example, the control plane interface between (R)AN 105 and the 5G core can support decoupling between AMF 155 and other functions (such as SMF 160) that may require control over services supported by the AN (e.g., control over UP resources in 105 for PDU sessions).

[0216] In the example, 5GC can provide policy information from PCF 135 to UE 100. In one example, policy information may include: access network discovery and selection policy, UE 100 routing selection policy (URSP), SSC mode selection policy (SSCMSP), network slice selection policy (NSSP), DNN selection policy, non-seamless offloading policy, etc.

[0217] In one example, such as Figure 5A and Figure 5B As described, the Registration Management (RM) can be used to register or deregister UE / User 100 in the network and establish user contexts in the network. Connection Management can be used to establish and release signaling connections between UE 100 and AMF155.

[0218] In the example, UE 100 can register on the network to receive services that require registration. In the example, UE 100 can periodically update its registration on the network to maintain reachability (periodic registration update), or update it while on the move (e.g., mobile registration update), or update its capabilities or renegotiate protocol parameters.

[0219] In the example, as shown in the example Figure 8 and Figure 9 The initial registration procedure described may involve performing network access control functions (e.g., user authentication and access authorization based on subscription profiles in UDM 140). Example Figure 9 yes Figure 8 The initial registration procedure described herein continues. Due to the initial registration procedure, the identity of service AMF 155 can be registered in UDM 140.

[0220] In the example, the registration management RM program can be applied to both 3GPP Access 105 and non-3GPP Access 165.

[0221] Example Figure 5AThe RM state of UE 100 as observed by UE 100 and AMF 155 can be depicted. In an exemplary implementation, two RM states reflecting the registration status of UE 100 in the selected PLMN can be employed in UE 100 and AMF 155: RM-DEREGISTERED 500 and RM-REGISTERED (RM-registered) 510. In the example, in RM-DEREGISTERED state 500, UE 100 may not be registered in the network. The UE 100 context in AMF 155 may not maintain valid location or routing information for UE 100, therefore UE 100 may not be reachable via AMF 155. In the example, the UE 100 context may be stored in both UE 100 and AMF 155. In the example, in RM REGISTERED state 510, UE 100 may be registered on the network. In RM-REGISTERED state 510, UE 100 may receive services that may require registration on the network.

[0222] In an exemplary implementation, two RM states that reflect the registration status of UE 100 in the selected PLMN can be adopted for UE 100 in AMF 155: RM-DEREGISTERED 520 and RM-REGISTERED 530.

[0223] As shown in the example Figure 6A and Figure 6B As depicted, the connection management CM may include establishing and releasing a signaling connection between UE 100 and AMF 155 via the N1 interface. This signaling connection can be used to enable NAS signaling exchange between UE 100 and the core network. The signaling connection between UE 100 and AMF 155 may include both a signaling connection between UE 100 and (R)AN 105 (e.g., an RRC connection via 3GPP access) and an N2 connection between UE 100 and AMF 155.

[0224] As exemplary Figure 6A and Figure 6BAs described, the NAS signaling connection between UE 100 and AMF 155 can employ two CM states: CM-IDLE (600, 620) and CM-CONNECTED (610, 630). UE 100 in CM-IDLE (600) state can be in RM-REGISTERED (510) state and may not have a NAS signaling connection established with AMF 155 via N1. UE 100 can perform cell selection, cell reselection, PLMN selection, etc. UE 100 in CM-CONNECTED (610) state can have a NAS signaling connection with AMF 155 via N1.

[0225] In the example implementation, for UE 100 at AMF 155, two CM states can be used, namely CM-IDLE620 and CM-CONNECTED 630.

[0226] In the example, the RRC inactivity state can be applied to NG-RAN (e.g., it can be applied to NR and E-UTRA connected to a 5G CN). Based on network configuration, AMF 155 can provide auxiliary information to NG RAN 105 to assist NG RAN 105 in determining whether UE 100 can be sent to the RRC inactivity state. When UE 100 is in CM-CONNECTED 610 in the RRC inactivity state, UE 100 can continue the RRC connection as a response to RAN 105 paging due to uplink data pending, mobile-initiated signaling procedures, etc., to notify the network that it has left the RAN 105 notification area, etc.

[0227] In the example, NAS signaling connection management may include establishing and releasing NAS signaling connections. The NAS signaling connection establishment function can be provided by UE 100 and AMF155 to establish a NAS signaling connection for UE 100 in CM-IDLE 600 state. The procedure for releasing the NAS signaling connection can be initiated by the 5G(R)AN 105 node or AMF 155.

[0228] In the example, UE 100's reachability management can detect whether UE 100 is reachable and can provide UE 100's location (e.g., access node) to the network to reach UE 100. Reachability management can be accomplished by paging UE 100 and UE 100 location tracking. UE 100 location tracking can include both UE 100 registration area tracking and UE 100 reachability tracking. During registration and registration update procedures, UE 100 and AMF 155 can negotiate UE 100 reachability characteristics in CM-IDLE 600, 620 states.

[0229] In the example, for CM-IDLE 600 and 620 states, two UE100 reachability categories can be negotiated between UE 100 and AMF 155. 1) When UE 100 is in CM-IDLE 600 mode, UE 100 reachability allows the mobile device to terminate data. 2) Mobile-Initiated Connection Only (MICO) mode. 5GC can support PDU connection services, which provide PDU exchange between UE 100 and the data network identified by the DNN. PDU connection services can be supported via PDU sessions established at the request of UE 100.

[0230] In the example, a PDU session can support one or more PDU session types. A PDU session can be established, modified (e.g., based on a request from UE 100), and / or released (e.g., based on a request from both UE 100 and 5GC) using NAS SM signaling exchanged via N1 between UE 100 and SMF160. Upon request from the application server, 5GC can trigger a specific application within UE 100. When a trigger is received, UE 100 can send it to the identified application within UE 100. The identified application within UE 100 can establish a PDU session for a specific DNN.

[0231] In the example, the 5G QoS model can support the following: Figure 7 The framework described herein is based on QoS flows. The 5G QoS model can simultaneously support QoS flows that require guaranteed flow bit rates and QoS flows that do not require guaranteed flow bit rates. In the example, the 5G QoS model can support reflection QoS. The QoS model may include flow mapping or packet marking at UPF 110 (CN_UP) 110, AN 105, and / or UE 100. In the example, packets can arrive at and / or be assigned to the application / service layer 730 of UE 100, UPF 110 (CN_UP) 110, and / or AF 145.

[0232] In the example, a QoS flow can be a granularity of QoS differentiation within a PDU session. QoS flow IDs and QFIs can be used to identify QoS flows in a 5G system. In the example, user plane traffic with the same QFI within a PDU session can receive the same traffic forwarding processing. The QFI can be carried in the encapsulation header on N3 and / or N9 (e.g., without changing the end-to-end packet header). In the example, the QFI can be applied to PDUs with different types of payloads. The QFI can be unique within a PDU session.

[0233] In the example, the QoS parameters of the QoS flow can be provided as a QoS profile to (R)AN 105 via N2 during PDU session establishment, QoS flow establishment, or each time the user plane is activated using NG-RAN. In the example, each PDU session may require default QoS rules. SMF 160 can assign QFIs to the QoS flow and can derive QoS parameters from information provided by PCF 135. In the example, SMF 160 can provide the (R)AN 105 with the QFIs and a QoS profile containing the QoS parameters of the QoS flow.

[0234] In the example, a 5G QoS flow can be the granularity of QoS forwarding processing in a 5G system. Traffic mapped to the same 5G QoS flow can receive the same forwarding processing (e.g., scheduling policies, queue management policies, rate setting policies, RLC configuration, etc.). In the example, providing different QoS forwarding processing may require separate 5G QoS flows.

[0235] In the example, the 5G QoS indicator can be a scalar that can be used as a reference for specific QoS forwarding behaviors (e.g., packet loss rate, packet delay budget) to be provided to the 5G QoS flow. In one example, the 5G QoS indicator can be implemented in the access network by 5QI reference node-specific parameters (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configurations, etc.) that control QoS forwarding processing.

[0236] In one example, 5GC can support edge computing and enable operators and third-party services to be hosted close to the UE's attached access point. The 5G core network can select a UPF 110 close to UE 100 and can perform traffic redirection from UPF 110 to the local data network via the N6 interface. In this example, selection and traffic redirection can be based on UE 100's subscription data, UE 100's location, information from application function AF 145, policies, other relevant traffic rules, and so on. In this example, the 5G core network can expose network information and capabilities to edge computing application functions. Edge computing functionality support may include: local routing, where the 5G core network can select UPF 110 to route user traffic to the local data network; traffic redirection, where the 5G core network can select traffic to be routed to applications in the local data network; session and service continuity for UE100 and application mobility; user plane selection and reselection, for example, based on input from application functions; network capability openness, where the 5G core network and application functions can provide information to each other via NEf 125; QoS and charging, where PCF 135 can provide QoS control and charging rules for traffic routed to the local data network; support for LAN data networks, where the 5G core network can provide support for connectivity to LADN in specific areas where applications are deployed; and so on.

[0237] An example 5G system could be a 3GPP system including a 5G access network 105, a 5G core network, and a UE 100. The permitted NSSAI could be an NSSAI provided by the serving PLMN during, for example, the registration process, indicating the network-permitted NSSAI for UE 100 within the serving PLMN of the currently registered area.

[0238] In the example, the PDU connectivity service can provide PDU exchange between UE 100 and the data network. A PDU session can be an association between UE 100 and data network DN 115 that provides the PDU connectivity service. The association type can be IP, Ethernet, and / or unstructured.

[0239] The user plane connection to the data network established via the network slice instance may include the following: executing the RM procedure to select the AMF 155 that supports the required network slice, and the number of one or more PDU sessions established to the required data network via the network slice instance.

[0240] In the example, the network slice set of UE 100 can be changed at any time when UE 100 can register on the network, and can be initiated by the network or UE 100.

[0241] In the example, periodic registration updates could mean that UE 100 re-registers when the periodic registration timer expires. The requested NSSAI could be an NSSAI that UE 100 can provide to the network.

[0242] In the example, a service-based interface can represent a set of services that can be provided / exposed by a given NF.

[0243] In the example, service continuity can refer to an uninterrupted user experience of the service, including situations where the IP address and / or anchor point can change. In the example, session continuity can refer to the continuity of a PDU session. For IP-type PDU sessions, session continuity can imply that the IP address is retained throughout the lifetime of the PDU session. The uplink classifier can be a UPF 110 function, designed to redirect uplink traffic to the data network DN 115 based on filter rules provided by SMF 160.

[0244] In the example, the 5G system architecture can support data connectivity and services, enabling deployments using technologies such as network function virtualization and / or software-defined networking. The 5G system architecture can leverage service-based interactions between identified control plane (CP) network functions. In the 5G system architecture, the separation of user plane (UP) functions from control plane functions can be considered. If needed, the 5G system can enable network functions to interact directly with other NFs.

[0245] In this example, a 5G system can reduce the dependency between the access network (AN) and the core network (CN). The architecture may include an aggregated access-agnostic core network with a common AN-CN interface, which can integrate different 3GPP and non-3GPP access types.

[0246] In the example, the 5G system can support a unified authentication framework, stateless network nodes (NFs) with separate compute and storage resources, open capabilities, and simultaneous access to local and centralized services. To support low-latency services and access to local data networks, the UP (Upload and Activation) function can be deployed close to the access network.

[0247] In the example, the 5G system can support roaming within the visited PLMN using home routing traffic and / or local breakout traffic. The example 5G architecture can be service-based, and the interaction between network functions can be represented in two ways: (1) as a service-based representation (in the example...) Figure 1(2) As a reference point representation, it shows the interaction between NF services in the network functions described by the point-to-point reference point (e.g., N11) between any two network functions.

[0248] In the example, network slices may include core network control plane and user plane network functions, 5G radio access networks, N3IWF functions for non-3GPP access networks, and so on. Network slices can vary depending on the supported features and network function implementations. Operators can deploy multiple network slice instances that deliver the same features but are used for different groups of UEs, for example, when they deliver different committed services and / or because they can be dedicated to a customer. The NSSF120 can store mapping information between slice instance IDs and NF IDs (or NF addresses).

[0249] In the example, UE 100 can be served simultaneously by one or more network slice instances via 5G-AN. In the example, UE 100 can be served by k network slices at a time (e.g., k=8, 16, etc.). Logically, the AMF155 instance serving UE 100 can belong to the network slice instance serving UE 100.

[0250] In the example, each PLMN can have a PDU session belonging to a specific network slice instance. Different network slice instances may not share PDU sessions. Different slices can have slice-specific PDU sessions using the same DNN.

[0251] S-NSSAI (Single Network Slice Selection Auxiliary Information) identifies network slices. S-NSSAI may include: Slice / Service Type (SST), which may refer to the expected network slice behavior in terms of characteristics and services; and / or Slice Differentiator (SD). The Slice Differentiator may be optional information that supplements the Slice / Service Type to allow further differentiation to select a network slice instance from multiple potential network slice instances conforming to the indicated Slice / Service Type. In the example, the same network slice instance employing different S-NSSAIs can be selected. The CN portion of the network slice instance serving UE 100 can be selected by the CN.

[0252] In the example, subscription data may include the S-NSSAI of the network slice subscribed by UE 100. One or more S-NSSAIs may be marked as the default S-NSSAI. In the example, k S-NSSAIs may be marked as the default S-NSSAI (e.g., k = 8, 16, etc.). In the example, UE 100 may subscribe to more than 8 S-NSSAIs.

[0253] In the example, UE 100 can be configured by an HPLMN, each PLMN being configured with an NSSAI. After successfully completing the UE's registration procedure, UE 100 can obtain the allowed NSSAI for this PLMN from AMF 155, which may include one or more S-NSSAIs.

[0254] In the example, the allowed NSSAI of the PLMN can take precedence over the configured NSSAI. UE 100 can use the S-NSSAI corresponding to the network slice used in the serving PLMN for subsequent network slice selection procedures within the allowed NSSAI.

[0255] In the example, establishing a user plane connection to the data network via a network slice instance may include: executing the RM procedure to select an AMF 155 that supports the required network slice, the number of one or more PDU sessions established to the required data network via the network slice instance, and so on.

[0256] In the example, when UE 100 registers with the PLMN, if UE 100 has a configured NSSAI or an allowed NSSAI for the PLMN, UE 100 can provide the requested NSSAI (which includes the S-NSSAI corresponding to the slice UE 100 is attempting to register for), a temporary user ID (if a temporary user ID is assigned to the UE), etc., to the network and NAS layers in the RRC. The requested NSSAI can be a configured NSSAI, an allowed NSSAI, etc.

[0257] In the example, when UE 100 registers with the PLMN, if UE 100 does not have a configured NSSAI or an allowed NSSAI for the PLMN, then RAN 105 can route NAS signaling from UE 100 to the default AMF 155 / route NAS signaling from the default AMF to the UE.

[0258] In the example, based on local policies, subscription changes, and / or UE 100 mobility, the network can change the set of permitted network slices to which UE 100 is registered. In the example, the network can perform the change during the registration process or use an RM procedure (which can trigger the registration process) to notify UE 100 of the change in supported network slices. The network can provide UE 100 with the new list of allowed NSSAI and tracking areas.

[0259] In the example, during the registration process in the PLMN, if the network determines that UE 100 should be served by a different AMF 155 based on network slicing, the AMF 155 that first receives the registration request can redirect the registration request to another AMF 155 via RAN 105 or via direct signaling between the initial AMF 155 and the target AMF 155.

[0260] In the example, the network operator can provide UE 100 with a Network Slice Selection Policy (NSSP). An NSSP may include one or more NSSP rules.

[0261] In one example, if UE 100 has a number of PDU sessions established corresponding to a specific S-NSSAI, UE 100 can route application user data within a single PDU session unless other conditions in UE 100 prevent the use of a PDU session. If the application provides a Data Navigate (DNN), UE 100 can consider the DNN to determine which PDU session to use. In the example, if UE 100 does not have a PDU session established with a specific S-NSSAI, UE 100 can request a new PDU session corresponding to the S-NSSAI and with a DNN that can be provided by the application. In the example, in order for RAN 105 to select appropriate resources to support network slices in RAN 105, RAN 105 can know the network slice used by UE 100.

[0262] In the example, when UE 100 triggers the establishment of a PDU session, AMF 155 can select SMF 160 from the network slice instance based on S-NSSAI, DNN, and / or other information (e.g., UE 100 subscriptions and local operator policies). The selected SMF160 can then establish a PDU session based on S-NSSAI and DNN.

[0263] In the example, to support network control privacy of slice information of slices accessible to UE 100, UE 100 may exclude NSSAI in NAS signaling when UE 100 is aware of or configured to allow privacy considerations to apply to NSSAI, unless UE 100 has a NAS security context and UE 100 may exclude NSSAI in unprotected RRC signaling.

[0264] In the example, for roaming scenarios, network slice-specific network functions (NFs) can be selected in both the VPLMN and HPLMN based on the S-NSSAI provided by the UE 100 during PDU connection establishment. If a standardized S-NSSAI is used, each PLMN can select slice-specific NF instances based on the provided S-NSSAI. In the example, the VPLMN can map the HPLMN's S-NSSAI to the VPLMN's S-NSSAI based on the roaming protocol (e.g., including the default S-NSSAI mapped to the VPLMN). In the example, slice-specific NF instances can be selected in the VPLMN based on the VPLMN's S-NSSAI. In the example, any slice-specific NF instance in the HPLMN can be selected based on the HPLMN's S-NSSAI.

[0265] As shown in the example Figure 8 and Figure 9 As described, the UE 100 can perform a registration procedure to obtain authorization for receiving services, to enable mobile tracking, to achieve accessibility, and so on.

[0266] In the example, UE 100 can send AN message 805 to (R)AN 105 (including AN parameters, RM-NAS registration request (registration type, SUCI or SUPI or 5G-GUTI, last accessed TAI (if available), security parameters, requested NSSAI, mapping of the requested NSSAI, UE 100 5GC capability, PDU session status, PDU session to be reactivated, follow-up requests, MICO mode preference, etc.) etc.). In the example, in the case of NG-RAN, parameters may include, for example, SUCI or SUPI or 5G-GUTI, the selected PLMN ID, and the requested NSSAI. In the example, parameters may include the establishment reason. The establishment reason can provide the reason for requesting to establish an RRC connection. In one example, the registration type could indicate whether UE 100 is to perform initial registration (i.e., UE 100 is in RM-DEREGISTERED state), mobile registration update (e.g., UE 100 is in RM-REGISTERED and the registration process is initiated due to mobility), periodic registration update (e.g., UE 100 is in RM-REGISTERED and the registration process can be initiated due to the periodic registration update timer expiring), or emergency registration (e.g., UE 100 is in a limited service state). In one example, if UE 100 performs initial registration to the PLMN (i.e., UE 100 is in RM-DEREGISTERED state) and UE 100 does not yet have a 5G-GUTI, UE 100 can include its SUCI or SUPI in the registration request. SUCI can be included if the home network has provided a public key to protect the SUPI in the UE. If UE 100 receives a UE 100 configuration update command indicating that UE 100 needs to re-register and that the 5G-GUTI is invalid, UE 100 can perform initial registration and may include a SUPI in the registration request message. For emergency registration, if UE 100 does not have a valid 5G-GUTI available, a SUPI may be included; when UE 100 has neither a SUPI nor a valid 5G-GUTI, a PEI may be included. In other cases, a 5G-GUTI may be included, and it may indicate the last serving AMF 155. If UE 100 has already registered via non-3GPP access in a new PLMN different from the 3GPP access (e.g., not the registered PLMN or an equivalent PLMN of the registered PLMN), UE 100 may not provide the 5G-GUTI assigned by AMF 155 via 3GPP access during the registration procedure via non-3GPP access.If UE 100 has already registered in a PLMN (e.g., a registered PLMN) that is different from a non-3GPP access PLMN (e.g., not a registered PLMN or an equivalent PLMN of a registered PLMN), then during the registration procedure via 3GPP access, UE 100 may not provide the 5G-GUTI assigned by AMF 155 via non-3GPP access. UE 100 may provide UE usage settings based on its configuration. In the case of initial registration or mobile registration update, UE 100 may include a mapping of requested NSSAIs, which may be a mapping of each S-NSSAI in the requested NSSAIs of the HPLMN to the S-NSSAIs in the configured NSSAIs, to ensure that the network can verify whether the S-NSSAIs in the requested NSSAIs are allowed based on the subscribed S-NSSAIs. If available, the previously accessed TAI may be included to help AMF 155 generate the UE's registration area. In the example, security parameters may be used for authentication and integrity protection. The requested NSSAIs may instruct network slice selection auxiliary information. The PDU session status can indicate previously established PDU sessions in the UE. When UE 100 is connected to two AMF 155s belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status can indicate the PDU sessions already established in the UE for the current PLMN. It may include PDU sessions awaiting reactivation to indicate that UE 100 may intend to activate a PDU session for its UP connection. When UE 100 is outside the availability area of ​​the LADN, the PDU session corresponding to the LADN may not be included in the PDU sessions awaiting reactivation. When UE 100 may have pending uplink signaling, and UE 100 may not include PDU sessions awaiting reactivation, it may include follow-up requests, or the registration type may indicate that UE 100 may need to perform emergency registration.

[0267] In the example, if including SUPI or 5G-GUTI does not indicate a valid AMF 155, then (R)AN 105 may select 808 AMF 155 based on (R)AT and the requested NSSAI (if available). If UE 100 is in CM-CONNECTED state, then (R)AN 105 may forward the registration request message to AMF 155 based on the UE's N2 connection. If (R)AN 105 can choose not to select an appropriate AMF 155, then it may forward the registration request to an AMF 155 that has been configured in (R)AN 105 to perform AMF 155 selection 808.

[0268] In the example, (R)AN 105 can send N2 message 810 to the new AMF 155 (including: N2 parameters, RM-NAS registration request (registration type, SUPI or 5G-GUTI, last accessed TAI (if available), security parameters, requested NSSAI, mapping of the requested NSSAI, UE 100 5GC capability, PDU session status, PDU session to be reactivated, follow-up requests, and MICO mode preferences), etc.). In the example, when using NG-RAN, the N2 parameters may include the selected PLMN ID, location information, cell identity, and RAT type related to the cell where UE 100 is located. In one example, when using NG-RAN, the N2 parameters may include the establishment reason.

[0269] In the example, the new AMF 155 can send Namf_Communication_UEContextTransfer (Full Registration Request) 815 to the old AMF 155. In one example, if the UE's 5G-GUTI is included in the registration request and the serving AMF 155 has changed since the last registration procedure, the new AMF 155 can invoke the Namf_Communication_UEContextTransfer service operation 815 (including the integrity-protected full registration request IE) on the old AMF 155 to request the UE's SUPI and MM context. The old AMF 155 can use the integrity-protected full registration request IE to verify that the context transfer service operation call corresponds to the requesting UE 100. In the example, the old AMF 155 can transfer the event subscription information for the UE for each NF consumer to the new AMF 155. In the example, if UE 100 identifies itself with PEI, the SUPI request can be skipped.

[0270] In the example, the old AMF 155 can send a Namf_Communication_UEContextTransfer response 815 (SUPI, MM context, SMF 160 information, PCF ID) to the new AMF 155. In the example, the old AMF 155 can respond to the Namf_Communication_UEContextTransfer call with the new AMF 155 including the UE's SUPI and MM context. In the example, if the old AMF 155 maintains information about the established PDU session, it can include SMF 160 information, including S-NSSAI, SMF 160 identity, and PDU session ID. In the example, if the old AMF 155 maintains information about the active NGAP UE-TNLA to the N3IWF, it can include information about the NGAP UE-TNLA binding.

[0271] In the example, if the SUCI is not provided by UE 100 or retrieved from the legacy AMF 155, the identity request procedure 820 can be initiated by the AMF 155 sending an identity request message to the UE 100 that requests the SUCI.

[0272] In the example, UE 100 can respond with an identity response message 820 that includes the SUCI. UE 100 can derive the SUCI using the public key of the provided HPLMN.

[0273] In the example, AMF 155 may decide to initiate UE 100 authentication 825 by calling AUSF 150. AMF 155 may select AUSF 150 based on SUPI or SUCI. In the example, if AMF 155 is configured to support emergency registration for unauthenticated SUPI and emergency registration of the registration type indicated by UE 100, AMF 155 may skip authentication and security settings, or AMF 155 may accept that authentication may fail and continue the registration procedure.

[0274] In the example, authentication 830 can be performed by the Nudm_UEAuthenticate_Get operation. AUSF 150 can discover UDM 140. If AMF 155 provides SUCI to AUSF 150, AUSF 150 can return SUPI to AMF 155 after successful authentication. In the example, if network slicing is used, AMF 155 can decide whether to reroute the registration request if the initial AMF 155 references AMF 155. In the example, AMF 155 can initiate NAS security functions. In the example, upon completing NAS security function settings, AMF 155 can initiate the NGAP procedure so that 5G-AN can use it to protect procedures with the UE. In the example, 5G-AN can store a security context and can acknowledge it to AMF 155. 5G-AN can use the security context to protect messages exchanged with the UE.

[0275] In the example, the new AMF 155 can send a Namf_Communication_RegistrationCompleteNotify 835 to the old AMF 155. If the AMF 155 has changed, the new AMF 155 can notify the old AMF 155 that UE100 can complete its registration in the new AMF 155 by calling the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication / security procedure fails, registration can be refused, and the new AMF 155 can call the Namf_Communication_RegistrationCompleteNotify service operation, with the refusal indication reason code directed to the old AMF 155. The old AMF 155 can continue as if it never received the UE 100 context transport service operation. If one or more of the S-NSSAIs used in the old registration area cannot be served in the target registration area, the new AMF 155 can determine which PDU sessions may not be supported in the new registration area. The new AMF 155 can invoke the Namf_Communication_RegistrationCompleteNotify service operation to the old AMF 155, including the rejected PDU session ID and the reason for rejection (e.g., S-NSSAI becomes unavailable). The new AMF 155 can modify the PDU session state accordingly. The old AMF 155 can notify the corresponding SMF 160 to release the UE's SM context locally by invoking the Nsmf_PDUSession_ReleaseSMContext service operation.

[0276] In the example, the new AMF 155 can send an Identity Request / Response 840 (e.g., PEI) to UE 100. If the PEI is not provided by UE 100 or retrieved from the old AMF 155, the Identity Request procedure can be initiated by sending an Identity Request message to UE 100 via AMF 155 to retrieve the PEI. Unless UE 100 performs emergency registration, the PEI may be transmitted encrypted and may not be authenticated. For emergency registration, UE 100 may have already included the PEI in the registration request.

[0277] In the example, the new AMF 155 can initiate an ME identity check 845 by calling the N5g-eir_EquipmentIdentityCheck_Get service operation 845.

[0278] In the example, based on SUPI, the new AMF 155 can be selected as a 905UDM 140. UDM 140 can be selected as a UDR instance. In the example, AMF 155 can be selected as a UDM 140.

[0279] In the example, if AMF 155 has changed since the last registration procedure, or if UE 100 provides a SUPI that may not reference a valid context in AMF 155, or if UE 100 is registered to the same AMF 155 but has already registered to a non-3GPP access (e.g., UE 100 registered via a non-3GPP access and can initiate a registration procedure to add 3GPP access), the new AMF 155 can register with UDM 140 using Nudm_UECM_Registration 910 and can subscribe to be notified by UDM 140 when AMF 155 registration can be cancelled. UDM 140 can store the AMF 155 identifier associated with the access type and may not delete the AMF 155 identifier associated with another access type. UDM 140 can store information provided by Nudr_UDM_Update during registration in the UDR. In the example, AMF 155 can retrieve access and mobile subscription data and SMF 160 select subscription data using Nudm_SDM_Get 915. UDM 140 can retrieve this information (access and mobile subscription data) from the UDR via Nudr_UDM_Query. After receiving a successful response, AMF 155 can subscribe to be notified when the requested data can be modified using Nudm_SDM_Subscribe 920. UDM 140 can subscribe to the UDR via Nudr_UDM_Subscribe. If the GPSI is available in the UE 100 subscription data, it can be provided from UDM 140 to AMF 155 in the subscription data. In the example, the new AMF 155 can provide the access type it serves for UE 100 to UDM 140, and this access type can be set to 3GPP access. UDM 140 can store the associated access type in the UDR along with the serving AMF 155 via Nudr_UDM_Update. The new AMF 155 can create an MM context for UE100 after obtaining mobile subscription data from UDM 140. In the example, when UDM 140 stores the associated access type along with the serving AMF 155, UDM 140 can initiate Nudm_UECM_DeregistrationNotification921 to the old AMF 155 corresponding to the 3GPP access. The old AMF 155 can then remove the UE's MM context. If the reason for service NF deletion indicated by UDM 140 is initial registration, the old AMF 155 can call the Namf_EventExposure_Notify service operation to all associated SMFs 160 of UE100 to notify UE100 to deregister from the old AMF 155. SMF 160 can release the PDU session upon receiving this notification.In the example, the old AMF 155 can use Nudm_SDM_unsubscribe 922 to unsubscribe from UDM 140 for subscription data.

[0280] In the example, if AMF 155 decides to initiate PCF 135 communication, for example, if AMF 155 has not yet obtained the access and mobility policy of UE 100, or if the access and mobility policy in AMF 155 is no longer valid, AMF 155 can choose 925PCF 135. If the new AMF 155 receives a PCF ID from the old AMF 155 and successfully contacts the PCF 135 identified by the PCF ID, then AMF 155 can choose the (V-)PCF identified by the PCF ID. If the PCF 135 identified by the PCF ID may not be used (e.g., there is no response from PCF 135), or if a PCF ID has not been received from the old AMF 155, then AMF 155 can choose 925PCF 135.

[0281] In the example, the new AMF 155 can perform policy association establishment 930 during the registration procedure. If the new AMF 155 contacts the PCF 135 identified by the (V-)PCF ID received during movement between AMFs 155, the new AMF 155 can include the PCF-ID in the Npcf_AMPolicyControl Get operation. If the AMF 155 notifies the PCF 135 of movement restrictions (e.g., UE 100 orientation) for adjustment, or if the PCF 135 updates its own movement restrictions due to certain conditions (e.g., application in use, time and date), the PCF 135 can provide the updated movement restrictions to the AMF 155.

[0282] In the example, PCF 135 can invoke Namf_EventExposure_Subscribe service operation 935 for UE 100 event subscription.

[0283] In the example, AMF 155 can send Nsmf_PDUSession_UpdateSMContext 936 to SMF 160. In the example, if the PDU session to be reactivated is included in the registration request, AMF 155 can invoke Nsmf_PDUSession_UpdateSMContext. AMF 155 can send the Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session to activate the user plane connection of the PDU session. SMF 160 can decide to trigger, for example, intermediate UPF 110 insertion, removal, or PSA modification. In the case of performing intermediate UPF 110 insertion, removal, or relocation for a PDU session not included in the PDU session to be reactivated, the procedure can be executed without N11 and N2 interaction to update the N3 user plane between (R)AN 105 and 5GC. The AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160 when any PDU session state indicates that it has been released at UE 100. The AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160 to release any network resources associated with the PDU session.

[0284] In the example, the new AMF 155 can send an N2 AMF 155 Mobility Request 940 to the N3IWF. If the AMF 155 has changed, the new AMF 155 can create an NGAP UE 100 association for the N3IWF connected to UE 100. In the example, the N3IWF can respond to the new AMF 155 with an N2 AMF 155 Mobility Response 940.

[0285] In the example, the new AMF 155 can send a Registration Acceptance 955 to UE 100 (including: 5G-GUTI, registration area, mobility restrictions, PDU session state, allowed NSSAI, [mapping of allowed NSSAI], periodic registration update timer, LADN information and accepted MICO mode, indication of IMS voice support via PS session, emergency service support indicator, etc.). In the example, AMF 155 can send a Registration Acceptance message to UE 100 indicating that the registration request has been accepted. If AMF 155 has assigned a new 5G-GUTI, it can include the 5G-GUTI. If AMF 155 has assigned a new registration area, it can send the registration area to UE 100 via the Registration Acceptance message 955. If the registration acceptance message does not include the registration area, UE 100 may consider the old registration area valid. In the example, mobility restrictions can be included if they apply to UE 100 and the registration type may not be emergency registration. AMF 155 can indicate the established PDU session to UE 100 in the PDU session state. UE 100 can locally remove any internal resources associated with a PDU session not marked as established in the received PDU session state. In the example, when UE 100 is connected to two AMF 155s belonging to different PLMNs via 3GPP access and non-3GPP access, UE 100 can locally remove any internal resources associated with the current PLMN's PDU session that are not marked as established in the received PDU session state. If PDU session state information is in the registration request, AMF 155 can indicate the PDU session state to the UE. The mapping of allowed NSSAIs can be a mapping of each S-NSSAI in the allowed NSSAIs of the HPLMN to an S-NSSAI in the configured NSSAIs. AMF 155 can include LADN information of the LADN in the registration acceptance message 955, the LADN being available in the registration area determined by AMF 155 for the UE. If UE100 includes MICO mode in its request, AMF 155 can respond to whether MICO mode can be used. AMF 155 can set an indication to support IMS voice via PS session. In the example, to set the indication to support IMS voice via PS session, AMF 155 can execute a UE / RAN radio information and compatibility request procedure to check the compatibility of UE 100 and RAN radio capabilities related to IMS voice via PS. In the example, an emergency service support indicator can notify UE 100 to support emergency services; for example, UE 100 can request emergency services via a PDU session. In the example, the handover restriction list and UE-AMBR can be provided to the NG-RAN by AMF 155.

[0286] In the example, UE 100 can send a registration complete 960 message to the new AMF 155. In the example, UE 100 can send the registration complete message 960 to AMF 155 to confirm that a new 5G-GUTI can be allocated. In the example, when information about the PDU session to be reactivated is not included in the registration request, AMF 155 can release the signaling connection with UE 100. In the example, when a subsequent request is included in the registration request, AMF 155 may not release the signaling connection after the registration procedure is completed. In the example, if AMF 155 realizes that some signaling is pending in AMF 155 or between UE 100 and 5GC, AMF 155 may not release the signaling connection after the registration procedure is completed.

[0287] As exemplary Figure 10 and Figure 11 As described, a service request procedure (e.g., a service request procedure triggered by UE 100) can be used by UE 100 in CM-IDLE state to request the establishment of a secure connection to AMF 155. Figure 11 It describes the service request procedure. Figure 10 The following diagram continues. The service request procedure can be used to activate user plane connectivity for established PDU sessions. The service request procedure can be triggered by UE 100 or 5GC, and can be used when UE 100 is in CM-IDLE and / or CM-CONNECTED, and can allow selective activation of user plane connectivity for some established PDU sessions.

[0288] In the example, UE 100, in CM IDLE state, can initiate a service request procedure to send uplink signaling messages, user data, etc., in response to a network paging request, and so on. In the example, after receiving the service request message, AMF 155 can perform authentication. In the example, after establishing a signaling connection to AMF 155, UE 100 or the network can send signaling messages such as PDU session establishment messages from UE 100 to SMF 160 via AMF 155.

[0289] In the example, for any service request, the AMF 155 can respond with a service accept message to synchronize the PDU session state between UE100 and the network. If the service request may not be accepted by the network, the AMF 155 can respond to UE100 with a service deny message. The service deny message may include an instruction or reason code requesting UE100 to perform a registration update procedure. In the example, for a service request arising from user data, if user plane connection activation may fail, the network can take further action. In the example... Figure 10 and Figure 11 In this context, more than one UPF may be involved, such as the old UPF110-2 and PDU session anchor PSA UPF 110-3.

[0290] In the example, UE 100 can send an AN message to (R)AN 105, which includes AN parameters, mobility management, MM NAS service request 1005 (e.g., a list of PDU sessions to be activated, a list of allowed PDU sessions, security parameters, PDU session status, etc.), etc. In the example, when UE 100 can reactivate a PDU session, UE 100 can provide a list of PDU sessions to be activated. When the service request can be a response to a paging or NAS notification, the list of allowed PDU sessions can be provided by UE 100, and can identify the access that can be transmitted to or the PDU session that can be associated with said access. In the example, for the NG-RAN case, parameters may include the selected PLMN ID and establishment reason. The establishment reason can provide the reason for requesting to establish an RRC connection. UE 100 can send a NAS service request message to RAN 105 for AMF 155 encapsulated in an RRC message.

[0291] In the example, if a service request can be triggered for user data, UE 100 can use a list of PDU sessions to be activated to identify the PDU sessions for which an UP connection will be activated in the NAS service request message. If a service request can be triggered by signaling, UE 100 may not be able to identify any PDU sessions. If this procedure can be triggered by a paging response, and / or UE 100 can simultaneously have user data to be transmitted, UE 100 can use a list of PDU sessions to be activated to identify the PDU sessions for which its UP connection can be activated in the MM NAS service request message.

[0292] In the example, if a service request for 3GPP access can be triggered in response to a paging indicating non-3GPP access, the NAS service request message can identify a list of PDU sessions associated with non-3GPP access that can be reactivated through 3GPP in the list of allowed PDU sessions. In the example, the PDU session status can indicate the PDU sessions available in UE 100. In the example, when UE 100 is outside the availability area of ​​the LADN, UE 100 may not trigger a service request procedure for the PDU session corresponding to the LADN. If a service request can be triggered for other reasons, UE 100 may not be able to identify such PDU sessions in the list of PDU sessions to be activated.

[0293] In the example, (R)AN 105 can send an N2 message 1010 (e.g., a service request) to AMF 155, including N2 parameters, MM NAS service requests, etc. If AMF 155 may not be able to process the service request, it can reject the N2 message. In the example, if NG-RAN is available, the N2 parameters may include 5G-GUTI, the selected PLMN ID, location information, RAT type, establishment reason, etc. In the example, the 5G-GUTI can be obtained in the RRC procedure, and (R)AN 105 can select AMF 155 based on the 5G-GUTI. In the example, the location information and RAT type may relate to the cell where UE 100 can camp. In the example, based on the PDU session state, AMF 155 can initiate a PDU session release procedure in the network for PDU sessions whose PDU session IDs can be indicated as unavailable by UE 100.

[0294] In the example, if the service request is not sent with integrity protection or integrity protection verification fails, the AMF155 can initiate NAS authentication / security procedure 1015.

[0295] In the example, if UE 100 triggers a service request to establish a signaling connection, then after the signaling connection is successfully established, UE 100 and the network can exchange NAS signaling.

[0296] In the example, AMF 155 can send a PDU session update context request 1020 to SMF 160, such as an Nsmf_PDUSession_UpdateSMContext request including PDU session ID, reason, UE 100 location information, access type, etc.

[0297] In the example, if UE 100 can identify the PDU session to be activated in the NAS service request message, the Nsmf_PDUSession_UpdateSMContext request can be invoked by AMF 155. In the example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by SMF 160, where the PDU session identified by UE 100 can be associated with a different PDU session ID than the one that triggered the procedure. In the example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by SMF 160, where the current UE 100 location can be outside the valid area of ​​the N2 information provided by SMF 160 during the network-triggered service request procedure. AMF 155 may choose not to send the N2 information provided by SMF 160 during the network-triggered service request procedure.

[0298] In one example, AMF 155 can identify the PDU session to be activated and can send an Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session, where the reason is set to indicate the establishment of user plane resources for the PDU session.

[0299] In one example, if the procedure can be triggered in response to a paging indicating non-3GPP access, and the list of allowed PDU sessions provided by UE100 may not include PDU sessions that have been paged to UE100, then AMF 155 may notify SMF 160 that the user plane of the PDU session may not be reactivated. The service request procedure may succeed without reactivating the user plane of any PDU session, and AMF 155 may notify UE100.

[0300] In the example, if the PDU session ID corresponds to an LADN, and SMF 160 determines that UE 100 may be outside the availability zone of the LADN based on the UE 100 location reported from AMF 155, then SMF 160 may decide (based on local policy) to maintain the PDU session, may refuse to activate the user plane connection for the PDU session, and may notify AMF 155. In the example, if the procedure can be triggered by a network-triggered service request, then SMF 160 may notify the UPF 110 initiating the data notification to abandon downlink data for the PDU session and / or not provide additional data notification messages. SMF 160 may respond to AMF 155 with an appropriate rejection reason and may stop user plane activation of the PDU session.

[0301] In the example, if the PDU session ID corresponds to an LADN, and the SMF 160 can determine that UE 100 may be outside the availability zone of the LADN based on the UE 100 location reported from the AMF 155, then the SMF 160 can decide (based on local policy) to release the PDU session. The SMF 160 can release the PDU session locally and can notify the AMF 155 that the PDU session can be released. The SMF 160 can respond to the AMF 155 with an appropriate rejection reason and can stop user plane activation of the PDU session.

[0302] In the example, if SMF 160 can accept UP activation for a PDU session, then based on the orientation information received from AMF 155, SMF 160 can check the UPF 110 selection criteria (e.g., slice isolation requirements, slice coexistence requirements, UPF 110 dynamic load, relative static capacity of UPF 110 among UPFs supporting the same DNN, UPF 110 orientation available at SMF 160, UE 100 orientation information, UPF 110 capabilities, and the features required for a specific UE 100 session). In the example, the appropriate UPF 110 can be determined by matching the features and characteristics required by UE 100, DNN, PDU session type (e.g., IPv4, IPv6, Ethernet type, or unstructured type), and (if applicable) static IP address / prefix, SSC mode selected for the PDU session, UE 100 subscription profile in UDM 140, including DNAI in the PCC rules, local operator policy, S-NSSAI, and other factors by the UE. The UE 100 may select (the access technology used, the logical topology of UPF 110, etc.) and may determine to perform one or more of the following: continue using the current UPF; if the UE 100 has moved out of the service area of ​​UPF 110 previously connected to (R)AN 105, while maintaining the UPF acting as the PDU session anchor, a new intermediate UPF 110 may be selected (or an intermediate UPF 110 may be added / removed); a PDU session re-establishment may be triggered to perform the relocation / reassignment of UPF 110 acting as the PDU session anchor, for example, if the UE 100 has moved out of the service area of ​​UPF 110 connected to RAN 105.

[0303] In the example, SMF 160 can send an N4 session establishment request 1030 to UPF 110 (e.g., a new intermediate UPF 110). In this example, if SMF 160 can choose the new UPF 110 to act as the intermediate UPF 110-2 for a PDU session, or if SMF 160 can choose to insert an intermediate UPF 110 for a PDU session that may not have an intermediate UPF 110-2, it can send an N4 session establishment request 1030 message to the new UPF 110, thereby providing packet inspection, data forwarding, enforcement, and reporting rules to be installed on the new intermediate UPF. The PDU session anchor addressing information (on N9) for this PDU session can be provided to the intermediate UPF 110-2.

[0304] In the example, if SMF 160 selects the new UPF 110 to replace the old (intermediate) UPF 110-2, SMF 160 may include a data forwarding indication. The data forwarding indication may instruct UPF 110 to reserve a second tunnel endpoint for buffered DL data from the old I-UPF.

[0305] In the example, the new UPF 110 (intermediate) can send an N4 session establishment response message 1030 to the SMF 160. If the UPF 110 can allocate CN tunnel information, it can provide the SMF 160 with the DL CN tunnel information and UL CN tunnel information (e.g., CN N3 tunnel information) of the UPF 110 used as the PDU session anchor. If a data forwarding indication is received, the new (intermediate) UPF 110, acting as the N3 endpoint, can send the DL CN tunnel information of the old (intermediate) UPF 110-2 to the SMF 160. The SMF 160 can start a timer to release resources in the old intermediate UPF 110-2.

[0306] In the example, if SMF 160 can select a new intermediate UPF 110 for the PDU session, or can remove the old I-UPF 110-2, then SMF 160 can send an N4 session modification request message 1035 to the PDU session anchor PSA UPF 110-3, thereby providing data forwarding instructions and DL tunnel information from the new intermediate UPF 110.

[0307] In the example, if a new intermediate UPF 110 can be added to the PDU session, then (PSA)UPF 110-3 can begin sending DL data to the new I-UPF 110, as indicated by the DL tunnel information.

[0308] In the example, if the service request can be triggered by the network, and the SMF 160 can remove the old I-UPF 110-2 without replacing it with a new I-UPF 110, then the SMF 160 can include a data forwarding indication in the request. The data forwarding indication can tell the (PSA) UPF 110-3 that a second tunnel endpoint can be reserved for buffered DL data from the old I-UPF 110-2. In this case, the PSA UPF 110-3 can begin buffering DL data that it may simultaneously receive from the N6 interface.

[0309] In the example, PSA UPF 110-3 (PSA) can send an N4 session modification response 1035 to SMF 160. In this example, if a data forwarding indication is received, PSA UPF 110-3 can become an N3 endpoint and can send CN DL tunnel information for the old (intermediate) UPF 110-2 to SMF 160. SMF 160 can start a timer to release any resources in the old intermediate UPF 110-2.

[0310] In the example, SMF 160 can send an N4 session modification request 1045 to the old UPF 110-2 (e.g., it may include the new UPF 110 address, the new UPF 110DL tunnel ID, etc.). In the example, if the service request can be triggered by the network, and / or SMF 160 can remove the old (intermediate) UPF 110-2, then SMF 160 can send an N4 session modification request message to the old (intermediate) UPF 110-2 and can provide DL tunnel information for buffered DL data. If SMF 160 can allocate a new I-UPF 110, the DL tunnel information comes from the new (intermediate) UPF 110, which can be used as the N3 endpoint. If SMF 160 does not allocate a new I-UPF 110, the DL tunnel information can come from the new UPF 110 (PSA) 110-3, which can be used as the N3 endpoint. SMF 160 can start a timer to monitor the forwarding tunnel. In the example, the old (intermediate) UPF 110-2 can send an N4 session modification response message to the SMF 160.

[0311] In the example, if I-UPF 110-2 can be relocated and a forwarding tunnel is established to the new I-UPF 110, then the old (intermediate) UPF 110-2 can forward its buffered data to the new (intermediate) UPF 110, which will serve as the N3 endpoint. In the example, if the old I-UPF 110-2 may be removed, and the new I-UPF 110 may not be allocated for a PDU session, and a forwarding tunnel may be established to UPF 110(PSA)110-3, then the old (intermediate) UPF 110-2 can forward its buffered data to UPF 110(PSA)110-3, which will serve as the N3 endpoint.

[0312] In the example, upon receiving an Nsmf_PDUSession_UpdateSMContext request with a reason (including, for example, the establishment of user plane resources), SMF 160 can send an N11 message 1060 to AMF 155, such as an Nsmf_PDUSession_UpdateSMContext response (including N1 SM container (PDU session ID, PDU session re-establishment indication), N2 SM information (PDU session ID, QoS profile, CN N3 tunnel information, S-NSSAI), and reason). SMF 160 can determine whether UPF 110 reallocation can be performed based on UE 100 location information, UPF 110 service area, and operator policy. In one example, when it can be determined that a PDU session of SMF 160 is served by the current UPF 110 (e.g., PDU session anchor or intermediate UPF), SMF 160 can generate N2 SM information and send an Nsmf_PDUSession_UpdateSMContext response 1060 to AMF 155 to establish a user plane. The N2 SM information may include information that AMF 155 can provide to RAN 105. In the example, for a PDU session that SMF 160 determines requires UPF 110 to relocate the PDU session anchor UPF, SMF 160 can refuse to activate the UP for the PDU session by sending an Nsmf_PDUSession_UpdateSMContext response containing an N1 SM container to UE 100 via AMF 155. The N1 SM container may include the corresponding PDU session ID and a PDU session re-establishment indication.

[0313] Upon receiving a Namf_EventExposure_Notify from AMF 155 to SMF 160 indicating that UE 100 is reachable, if SMF 160 may have pending DL data, SMF 160 may invoke the Namf_Communication_N1N2MessageTransfer service operation to AMF 155 to establish a user plane for a PDU session. In the example, in the case of DL data, SMF 160 may continue to send DL data notifications to AMF 155.

[0314] In the example, if the PDU session corresponds to an LADN and UE 100 may be outside the availability zone of the LADN, or if AMF 155 can notify SMF 160 that UE 100 is reachable for regulated priority services and the PDU session to be activated may not be used for regulated priority services; or if SMF 160 may decide to perform PSA UPF 110-3 relocation for the requested PDU session, then SMF 160 can send a message to AMF 155 to refuse the UP activation of the PDU session by including a reason in the Nsmf_PDUSession_UpdateSMContext response.

[0315] In the example, AMF 155 can send an N2 request message 1065 to (R)AN 105 (e.g., N2 SM information received from SMF 160, security context, AMF 155 signaling connection ID, handover restriction list, MM NAS service acceptance, and a list of recommended cell / TA / NG-RAN node identifiers). In the example, RAN 105 can store the security context, AMF 155 signaling connection ID, QoS information for the QoS flow of the PDU session that can be activated, and the N3 tunnel ID in the UE 100 RAN 105 context. In the example, the MM NAS service acceptance can include the PDU session state in AMF 155. If SMF 160 might refuse to activate the UP of the PDU session, the MM NAS service acceptance can include the PDU session ID and the reason why the user plane resource might not be activated (e.g., LADN is unavailable). Local PDU session release during the session request procedure can be indicated to UE 100 via the session state.

[0316] In the example, if there are a number of PDU sessions that may involve multiple SMF 160s, the AMF 155 may not wait for responses from all SMF 160s before it can send N2 SM information to the UE 100. The AMF 155 may wait for all responses from the SMF 160s before it can send an MM NAS service accept message to the UE 100.

[0317] In the example, if a procedure can be triggered for PDU session user plane activation, the AMF 155 may include at least one N2 SM information from the SMF 160. The AMF 155 may send additional N2 SM information from the SMF 160 in a separate N2 message (e.g., an N2 tunnel setup request, if present). Alternatively, if multiple SMFs 160s may be involved, the AMF 155 may send an N2 request message to the (R)AN 105 after receiving all Nsmf_PDUSession_UpdateSMContext response service operations from all SMFs 160s associated with the UE 100. In this case, the N2 request message may include the N2 SM information received in each Nsmf_PDUSession_UpdateSMContext response and the PDU session ID, enabling the AMF 155 to associate the response with the relevant SMF 160.

[0318] In the example, if the RAN 105 (e.g., NG RAN) node can provide a list of recommended cell / TA / NG-RAN node identifiers during the release procedure, the AMF 155 can include information from that list in the N2 request. RAN 105 can use this information to allocate RAN 105 notification areas when it may decide to enable RRC inactivity for UE 100.

[0319] If AMF 155 can receive from SMF 160 during the PDU session establishment procedure an indication that UE 100 may be using a PDU session related to a latency-sensitive service for any PDU session established for UE 100, and AMF 155 has received from UE 100 an indication that CM-CONNECTED can be supported in an RRC inactivity state, then AMF 155 may include the UE's RRC inactivity auxiliary information. In the example, AMF 155 based on network configuration may include the UE's RRC inactivity auxiliary information.

[0320] In the example, (R)AN 105 can send a message to UE 100 to perform an RRC connection reconfiguration 1070 with UE 100, depending on the QoS information of all QoS flows of the PDU session for which the UP connection can be activated, as well as the data radio bearer. In the example, user plane security can be established.

[0321] In the example, if the N2 request could include an MM NAS service acceptance message, RAN 105 could forward the MM NAS service acceptance to UE 100. UE 100 could then locally delete the context of a PDU session that might not be available in 5GC.

[0322] In one example, if N1 SM information can be transmitted to UE 100 and indicates that some PDU sessions can be re-established, then UE 100 can initiate PDU session re-establishment for PDU sessions that can be re-established after the service request procedure may be completed.

[0323] In one example, after the user plane radio resources can be configured, uplink data from UE 100 can be forwarded to RAN 105. RAN 105 (e.g., NG-RAN) can then send the uplink data to the provided UPF 110 address and tunnel ID.

[0324] In the example, (R)AN 105 can send an N2 request acknowledgment 1105 to AMF 155 (e.g., N2 SM information including: AN tunnel information, a list of accepted QoS flows for PDU sessions with UP connections active, and a list of rejected QoS flows for PDU sessions with UP connections active)). In the example, the N2 request message may include N2 SM information, such as AN tunnel information. RAN 105 can respond to the N2 SM information with a separate N2 message (e.g., an N2 tunnel setup response). In the example, if multiple N2 SM information items are included in the N2 request message, the N2 request acknowledgment may include multiple N2 SM information items and information that enables AMF 155 to associate the response with the relevant SMF 160.

[0325] In the example, AMF 155 can send an Nsmf_PDUSession_UpdateSMContext request 1110 (N2 SM information (AN tunnel information), RAT type) per PDU session to SMF 160. If AMF 155 can receive N2 SM information (one or more) from RAN 105, AMF 155 can forward the N2 SM information to the relevant SMF 160. If the UE 100 timezone may have changed compared to the last reported UE 100 timezone, AMF 155 can include the UE 100 timezone IE in the Nsmf_PDUSession_UpdateSMContext request message.

[0326] In the example, if a dynamic PCC is deployed, the SMF 160 can notify the PCF 135 of new location information (if subscribed) by invoking an event exposure notification operation (e.g., the Nsmf_EventExposure_Notify service operation). The PCF 135 can provide updated policies by invoking the policy control update notification message 1115 (e.g., the Npcf_SMPolicyControl_UpdateNotify operation).

[0327] In the example, if SMF 160 can select the new I-UPF 110 as the intermediate I-UPF 110 for the PDU session, then SMF 160 can initiate an N4 session modification procedure 1120 to the new I-UPF 110 and can provide AN tunneling information. Downlink data from the new I-UPF 110 can be forwarded to RAN 105 and UE 100. In one example, UPF 110 can send an N4 session modification response 1120 to SMF 160. In another example, SMF 160 can send an Nsmf_PDUSession_UpdateSMContext response 1140 to AMF 155.

[0328] In one example, if a forwarding tunnel to the new I-UPF 110 can be established, and if the timer set for the forwarding tunnel, SMF 160, may expire, SMF 160 can send an N4 session modification request 1145 to the new (intermediate) UPF 110, which serves as the N3 termination point, to release the forwarding tunnel. In the example, the new (intermediate) UPF 110 can send an N4 session modification response 1145 to SMF 160. In the example, SMF 160 can send an N4 session modification request 1150 or an N4 session release request to PSA UPF 110-3. In the example, if SMF 160 can continue to use the old UPF 110-2, SMF 160 can send an N4 session modification request 1155, thereby providing AN tunnel information. In the example, if SMF 160 can select the new UPF 110 as the intermediate UPF 110, and the old UPF 110-2 may not be PSA UPF 110-3, then SMF 160 can initiate resource release by sending an N4 session release request (release reason) to the old intermediate UPF 110-2 after the timer expires.

[0329] In the example, the old intermediate UPF 110-2 can send an N4 session modification response or an N4 session release response 1155 to the SMF 160. The old UPF 110-2 can use the N4 session modification response or N4 session release response message to acknowledge the modification or release of the resource. The AMF 155 can invoke the Namf_EventExposure_Notify service operation to notify the NFs that may have subscribed to the event of the move-related event after this procedure may complete. In the example, if SMF 160 has subscribed to UE 100 moving into or out of its region of interest and if the UE's current location indicates that it may be moving into or out of its subscribed region of interest, or if SMF 160 has subscribed to LADN DNN and if UE 100 may be moving into or out of an area where LADN is available, or if UE 100 may be in MICO mode and AMF 155 has notified UE 100 that SMF 160 is unreachable and SMF 160 may not send DL data notifications to AMF 155, and AMF 155 can notify SMF 160 that UE 100 is reachable, then AMF 155 can call Namf_EventExposure_Notify on SMF 160. Alternatively, if SMF 160 has subscribed to UE 100's reachability status, then AMF 155 can notify UE 100 of its reachability.

[0330] exist Figure 12 and Figure 13The document describes an example PDU session establishment procedure. In one exemplary implementation, when a PDU session establishment procedure is available, UE 100 may send a NAS message 1205 (or an SM NAS message) to AMF 155. This NAS message includes NSSAI, S-NSSAI (e.g., requested S-NSSAI, allowed S-NSSAI, subscribed S-NSSAI, etc.), DNN, PDU session ID, request type, old PDU session ID, N1 SM container (PDU session establishment request), etc. In the example, UE 100 may generate a new PDU session ID to establish a new PDU session. In the example, when emergency service may be required and an emergency PDU session may not yet be established, UE 100 may initiate a UE 100-requested PDU session establishment procedure, where the request type indicates an emergency request. In the example, UE 100 may initiate a UE 100-requested PDU session establishment procedure by transmitting a NAS message containing a PDU session establishment request within the N1 SM container. PDU session establishment requests may include PDU type, SSC mode, protocol configuration options, etc. In the example, if the PDU session establishment is a request to establish a new PDU session, the request type may indicate an initial request, and if the request involves an existing PDU session between 3GPP access and non-3GPP access or an existing PDN connection in an EPC, the request type may indicate an existing PDU session. In the example, if the PDU session establishment is a request to establish a PDU session for emergency services, the request type may indicate an emergency request. If the request involves an existing PDU session for emergency services between 3GPP access and non-3GPP access, the request type may indicate an existing emergency PDU session. In the example, a NAS message sent by UE 100 may be encapsulated in an N2 message sent to AMF 155 that may include user location information and access technology type information. In the example, the PDU session establishment request message may contain an SM PDU DN request container containing information about external DN authorization for the PDU session. In the example, if the procedure can be triggered for SSC Mode 3 operation, then UE 100 can include the old PDU session ID in the NAS message, which can indicate the PDU session ID of the ongoing PDU session to be released. The old PDU session ID can be an optional parameter that can be included in this case. In the example, AMF 155 can receive NAS messages (e.g., NAS SM messages) and user location information (e.g., cell ID in the case of RAN 105). In the example, when UE 100 is outside the availability area of ​​LADN, UE 100 may not trigger PDU session establishment corresponding to the PDU session of LADN.

[0331] In the example, AMF 155 can determine whether a NAS message or an SM NAS message corresponds to a request for a new PDU session based on the request type indicating an initial request and the PDU session ID not being used for any existing PDU session of UE100. If the NAS message does not contain an S-NSSAI, AMF 155 can determine the default S-NSSAI for the requested PDU session based on UE 100 subscriptions (if it can contain only one default S-NSSAI) or based on operator policies. In the example, AMF 155 can perform SMF 160 selection 1210 and select SMF 160. If the request type indicates an initial request or the request can be attributed to a handover from EPS, AMF 155 can store the association of the S-NSSAI, the PDU session ID, and the SMF 160 ID. In the example, if the request type is an initial request, and if the old PDU session ID indicating an existing PDU session can be included in the message, the AMF155 can select the SMF 160 and can store the association between the new PDU session ID and the selected SMF 160 ID.

[0332] In the example, AMF 155 can send N11 message 1215 to SMF 160, such as Nsmf_PDUSession_CreateSMContext request (including: SUPI or PEI, DNN, S-NSSAI, PDU session ID, AMF 155ID, request type, N1 SM container (PDU session establishment request), user location information, access type, PEI, GPSI), or Nsmf_PDUSession_UpdateSMContext request (SUPI, DNN, S-NSSAI, PDU session ID, AMF 155ID, request type, N1 SM container (PDU session establishment request), user location information, access type, RAT type, PEI). In the example, if AMF 155 may not be associated with SMF 160 of the PDU session ID provided by UE 100 (e.g., when the request type indicates an initial request), AMF 155 can invoke the Nsmf_PDUSession_CreateSMContext request. However, if AMF 155 is already associated with SMF 160 of the PDU session ID provided by UE 100 (e.g., when the request type indicates an existing PDU session), AMF 155 can invoke the Nsmf_PDUSession_UpdateSMContext request. In the example, AMF 155ID can be the UE's GUAMI, which uniquely identifies the AMF 155 serving UE 100. AMF 155 can forward the PDU session ID along with the N1 SM container containing the PDU session establishment request received from UE 100. When UE 100 registers for emergency services without providing SUPI, AMF 155 can provide PEI instead of SUPI. If UE 100 has registered for emergency services but has not yet been certified, AMF 155 can indicate that SUPI has not yet been certified.

[0333] In the example, if the request type may not indicate an urgent request or an existing urgent PDU session, and if SMF 160 has not yet registered and subscription data may be unavailable, SMF 160 may register with UDM 140 and may retrieve subscription data 1225 and be notified when subscription data can be modified. In the example, if the request type may indicate an existing PDU session or an existing urgent PDU session, SMF 160 may determine that the request is attributable to a handover between 3GPP access and non-3GPP access, or to a handover from EPS. SMF 160 may identify an existing PDU session based on the PDU session ID. SMF 160 may update an existing SM context instead of creating a new SM context, and may provide an updated representation of the SM context to AMF 155 in the response. If the request type may be an initial request, and if the old PDU session ID can be included in the Nsmf_PDUSession_CreateSMContext request, SMF 160 may identify the existing PDU session to be released based on the old PDU session ID.

[0334] In the example, SMF 160 can send N11 message response 1220 to AMF 155, such as a PDU session creation / update response, Nsmf_PDUSession_CreateSMContext response 1220 (reason, SM context ID or N1 SM container (PDU session rejected (reason))) or Nsmf_PDUSession_UpdateSMContext response.

[0335] In one example, if SMF 160 can perform secondary authorization / authentication 1230 during the establishment of a PDU session by the DN-AAA server, then SMF 160 can choose UPF 110 and can trigger PDU session establishment authentication / authorization.

[0336] In the example, if the request type indicates an initial request, the SMF 160 can select the SSC mode for the PDU session. The SMF 160 can select one or more UPFs as needed. In the case of an IPv4 or IPv6 PDU, the SMF 160 can assign an IP address / prefix to the PDU session. In the case of an IPv6 PDU, the SMF 160 can assign an interface identifier to the UE 100 so that the UE 100 can construct its link-local address. For unstructured PDU types, the SMF 160 can assign an IPv6 prefix to the PDU session and the N6 point-to-point tunnel (based on UDP / IPv6).

[0337] In the example, if a dynamic PCC is deployed, the SMF 160 can perform PCF 135 selection 1235. If the request type indicates an existing PDU session or an existing emergency PDU session, the SMF 160 can use PCF 135 already selected for the PDU session. If a dynamic PCC is not deployed, the SMF 160 can apply a local policy.

[0338] In the example, SMF 160 can execute Session Management Policy Establishment Procedure 1240 to establish a PDU session with PCF 135 and obtain the default PCC rules for the PDU session. GPSI can be included if available at SMF 160. If the request type in 1215 indicates an existing PDU session, SMF 160 can notify of events previously subscribed to by PCF 135 via the Session Management Policy Modification Procedure, and PCF 135 can update the policy information in SMF 160. PCF 135 can provide SMF 160 with an authorized session—AMBR—and authorized 5QI and ARP. PCF 135 can subscribe to IP allocation / release events in SMF 160 (and can subscribe to other events).

[0339] In the example, PCF 135, based on the Emergency DNN, can set the ARP of the PCC rule to a value that can be reserved for emergency services.

[0340] In the example, if the request type in 1215 indicates an initial request, the SMF 160 can select the SSC mode for the PDU session. The SMF 160 can select one or more UPFs in 1245 as needed. In the case of an IPv4 or IPv6 PDU, the SMF 160 can assign an IP address / prefix to the PDU session. In the case of an IPv6 PDU, the SMF 160 can assign an interface identifier to the UE100 so that the UE100 can build its link-local address. For unstructured PDU types, the SMF 160 can assign an IPv6 prefix (e.g., based on UDP / IPv6) to the PDU session and the N6 point-to-point tunnel. In the example, for a PDU session of the Ethernet PDU type, the SMF 160 cannot assign either a MAC address or an IP address to the UE100 for this PDU session.

[0341] In the example, if the request type in 1215 is an existing PDU session, then SMF 160 can maintain the same IP address / prefix that can be assigned to UE 100 in the source network.

[0342] In the example, if the request type in 1215 indicates an existing PDU session involving movement between 3GPP access and non-3GPP access, then SMF 160 can maintain the SSC mode of the PDU session, such as the current PDU session anchor and IP address. In the example, SMF 160 can trigger, for example, the insertion of a new intermediate UPF 110 or the allocation of a new UPF 110. In the example, if the request type indicates an urgent request, then SMF 160 can select 1245 UPF 110 and can select SSC mode 1.

[0343] In the example, the SMF 160 can execute a session management policy modification procedure 1250 to report certain events to a previously subscribed PCF 135. If the request type is an initial request, a dynamic PCC is deployed, and the PDU type is IPv4 or IPv6, the SMF 160 can notify the (previously subscribed) PCF 135 of the UE's assigned 100 IP address / prefix.

[0344] In the example, PCF 135 can provide updated policies to SMF 160. PCF 135 can provide authorized sessions - AMBR and authorized 5QI and ARP to SMF 160.

[0345] In the example, if the request type indicates an initial request, SMF 160 can initiate an N4 session establishment procedure 1255 with the selected UPF 110. SMF 160 can also initiate an N4 session modification procedure with the selected UPF 110. In the example, SMF 160 can send an N4 session establishment / modification request 1255 to UPF 110 and can provide packet detection, execution, reporting rules, etc., to be installed on UPF 110 for this PDU session. If CN tunneling information is allocated by SMF 160, it can be provided to UPF 110. If this PDU session requires selective user plane deactivation, SMF 160 can determine an inactive timer and provide it to UPF 110. In the example, UPF 110 can acknowledge this by sending an N4 session establishment / modification response 1255. If CN tunneling information is allocated by the UPF, it can be provided to SMF 160. In the example, if multiple UPFs are selected for a PDU session, then SMF 160 can initiate an N4 session creation / modification procedure 1255 with each UPF 110 of the PDU session.

[0346] In the example, SMF 160 can send the Namf_Communication_N1N2MessageTransfer1305 message to AMF 155 (including PDU session ID, access type, N2 SM information (PDU session ID, QFI, QoS profile, CN tunnel information, S-NSSAI, session-AMBR, PDU session type, etc.) and N1 SM container (PDU session establishment acceptance (QoS rules, selected SSC mode, S-NSSAI, assigned IPv4 address, interface identifier, session-AMBR, selected PDU session type, etc.))). In cases where multiple UPFs are used for a PDU session, the CN tunnel information may include tunnel information related to the UPF 110 terminating N3. In the example, the N2 SM information may carry information that the AMF 155 can forward to the (R)AN 105 (e.g., CN tunnel information corresponding to the core network address of the N3 tunnel corresponding to the PDU session, one or more QoS profiles and corresponding QFIs may be provided to the (R)AN 105, the PDU session ID may indicate the association between AN resources and the PDU session for UE 100 via AN signaling with UE 100, etc.). In the example, the PDU session may be associated with S-NSSAI and DNN. In the example, the N1 SM container may contain PDU session establishment acceptance that the AMF 155 can provide to UE 100. In the example, multiple QoS rules and QoS profiles may be included in the PDU session establishment acceptance within the N1 SM and the N2 SM information. In the example, Namf_Communication_N1N2MessageTransfer 1305 may also include the PDU session ID and information that allows the AMF 155 to know which access is used for UE 100.

[0347] In the example, AMF 155 can send an N2 PDU session request 1310 to (R)AN 105 (including N2 SM information, NAS message (PDU session ID, N1 SM container (PDU session establishment acceptance, etc.))). In the example, AMF 155 can send a NAS message 1310 to (R)AN 105, which may include a PDU session ID and a PDU session establishment acceptance for UE 100, as well as the N2 SM information received from SMF 160 within the N2 PDU session request 1310.

[0348] In the example, (R)AN 105 can issue an AN-specific signaling exchange 1315 with UE 100, which can be related to information received from SMF 160. In the example, in the case of 3GPP RAN 105, an RRC connection reconfiguration procedure can be performed with UE 100 to establish the necessary RAN 105 resources related to the QoS rules of PDU session request 1310. In the example, (R)AN 105 can allocate (R)AN 105N3 tunnel information for the PDU session. In the dual-connectivity case, the primary RAN 105 node can assign some (zero or more) QFIs to be configured to the primary RAN 105 node and assign other QFIs to the secondary RAN 105 node. The tunnel information can include the tunnel endpoints of each involved RAN 105 node and the QFIs assigned to each tunnel endpoint. QFIs can be assigned to either the primary or secondary RAN 105 node. In the example, (R)AN 105 can forward NAS message 1310 (PDU session ID, N1 SM container (PDU session establishment accepted)) to UE 100. If the necessary RAN 105 resources are established and (R)AN 105 tunnel information is successfully allocated, (R)AN 105 can provide the NAS message to UE 100.

[0349] In the example, the N2 PDU session response 1320 may include the PDU session ID, reason, N2 SM information (PDU session ID, AN tunnel information, list of accepted / rejected QFIs), etc. In the example, the tunnel information may correspond to the access network address of the N3 tunnel corresponding to the PDU session.

[0350] In the example, AMF 155 can forward N2 SM information received from (R)AN 105 to SMF 160 via Nsmf_PDUSession_UpdateSMContext request 1330 (including N2 SM information, request type, etc.). In one example, if the list of rejected QFIs is included in the N2 SM information, SMF 160 can release the QoS profile associated with the rejected QFI.

[0351] In the example, SMF 160 can initiate an N4 session modification procedure 1335 with UPF 110. SMF 160 can provide UPF 110 with AN tunnel information and corresponding forwarding rules. In the example, UPF 110 can provide an N4 session modification response 1335 to SMF 160.

[0352] In the example, SMF 160 can send an Nsmf_PDUSession_UpdateSMContext response 1340 (reason) to AMF 155. Following this step, SMF 160 can subscribe to UE 100 mobility event notifications (e.g., location reports, UE 100 moving into or out of the region of interest) from AMF 155 by invoking the Namf_EventExposure_Subscribe service operation. For LADN, SMF 160 can subscribe to UE 100 moving into or out of the LADN service area event notification by providing the LADN DNN as an indicator of the region of interest. AMF 155 can forward relevant events subscribed to by SMF 160.

[0353] In the example, SMF 160 can send Nsmf_PDUSession_SMContextStatusNotify(release) 1345 to AMF 155. In this example, if at any point during this procedure, the SMF 160 can notify the AMF 155 by calling Nsmf_PDUSession_SMContextStatusNotify(release) 1345, the SMF 160 can release any created N4 sessions, any PDU session addresses (if assigned) (e.g., IP addresses), and the association with PCF 135.

[0354] In the example, with the PDU type being IPv6, the SMF 160 can generate an IPv6 router advertisement 1350, which can be sent to the UE 100 via the N4 and UPF 110.

[0355] In the example, if a PDU session may not be established, the SMF 160 can use Nudm_SDM_Unsubscribe(SUPI, DNN, S-NSSAI) to unsubscribe from the modifications made by 1360 to the corresponding (SUPI, DNN, S-NSSAI) session management subscription data when the SMF 160 no longer processes the PDU session for this UE 100 (DNN, S-NSSAI). In another example, if a PDU session may not be established, the SMF 160 can use Nudm_UECM_Deregistration(SUPI, DNN, PDU session ID) to unregister 1360 for a given PDU session.

[0356] Figure 14 Another example of a mobile communication network in which embodiments of the present disclosure can be implemented is shown. Figure 14The mobile communication network depicted includes a wireless device 1410, a base station 1420, a physical core network deployment 1430 (hereinafter referred to as "CN deployment 1430") with one or more network functions, and a physical core network deployment 1440 (hereinafter referred to as "CN deployment 1440") with one or more network functions. Deployment 1430 and deployment 1440 may be elements of the core network.

[0357] Wireless device 1410 can communicate with base station 1420 via air interface 1470. The communication direction from wireless device 1410 to base station 1420 via air interface 1470 is called uplink, and the communication direction from base station 1420 to wireless device 1410 via air interface 1470 is called downlink. Downlink transmission can be separated from uplink transmission using some combination of FDD, TDD, and / or two duplex technologies. Figure 14 A single wireless device 1410 and a single base station 1420 are shown, but it should be understood that the wireless device 1410 can communicate with any number of base stations or other access network components via the air interface 1470, and the base station 1420 can communicate with any number of wireless devices via the air interface 1470.

[0358] Wireless device 1410 may include processing system 1411 and memory 1412. Memory 1412 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1412 may include instructions 1413. Processing system 1411 may process and / or execute instructions 1413. Processing and / or execution of instructions 1413 may cause processing system 1411 to perform one or more functions or activities. Memory 1412 may include data (not shown). One of the functions or activities performed by processing system 1411 may be storing data in memory 1412 and / or retrieving previously stored data from memory 1412. In one example, downlink data received from base station 1420 may be stored in memory 1412, and uplink data for transmission to base station 1420 may be retrieved from memory 1412. Wireless device 1410 may communicate with base station 1420 using transmission processing system 1414 and reception processing system 1415. Wireless device 1410 may include one or more antennas 1416 to access air interface 1470. Although Figure 14 Not shown, but the transmission processing system 1414 and / or the receiving processing system 1415 may be coupled to a dedicated memory similar to but separate from the memory 1412, and include instructions that can be processed and / or executed to perform one or more of their respective functions.

[0359] Wireless device 1410 may include one or more other elements 1419. These other elements 1419 may include software and / or hardware providing features and / or functionality, such as speakers, microphones, keyboards, displays, touchpads, satellite transceivers, universal serial bus (USB) ports, hands-free headsets, FM radio units, media players, internet browsers, electronic control units (e.g., for motor vehicles), and / or one or more sensors (e.g., accelerometers, gyroscopes, temperature sensors, radar sensors, lidar sensors, ultrasonic sensors, light sensors, cameras, GPS sensors, etc.). Wireless device 1410 may receive user input data from and / or provide user output data to these other elements 1419. These other elements 1419 may include a power source. Wireless device 1410 may receive power from the power source and may be configured to distribute power to other components within wireless device 1410. The power source may include one or more power sources, such as batteries, solar cells, fuel cells, or any combination thereof.

[0360] Wireless device 1410 can transmit data to base station 1420 via air interface 1470. To perform the transmission, processing system 1411 can implement Layer 3 and Layer 2 Open Systems Interconnection (OSI) functions to process data for uplink transmission. Layer 3 may include Radio Resource Control (RRC). Layer 14 may include Serving Data Application Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Media Access Control (MAC). Data can be provided to transmission processing system 1414, which can implement Layer 1 OSI functions. Layer 1 may include the Physical Layer (PHY). Wireless device 1410 can transmit data via air interface 1470 using one or more antennas 1416. Where one or more antennas 1416 include multiple antennas, the multiple antennas can be used to perform one or more multi-antenna techniques, such as spatial multiplexing (e.g., single-user multiple-input multiple-output (MIMO) or multi-user MIMO), transmit / receive diversity, and / or beamforming.

[0361] Wireless device 1410 can receive downlink data from base station 1420 via air interface 1470. The downlink data can be received via one or more antennas 1416. Receive processing system 1415 can implement Layer 1 OSI functions on the received downlink data and can provide the data to processing system 1411. Processing system 1411 can implement Layer 2 and Layer 3 OSI functions to process the received downlink data. Base station 1420 may include elements similar to those of wireless device 1410. Base station 1420 may include processing system 1421 and memory 1422. Memory 1422 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1422 may include instructions 1423. Processing system 1421 can process and / or execute instructions 1423. Processing and / or execution of instructions 1423 may cause processing system 1421 to perform one or more functions or activities. Memory 1422 may include data (not shown). One of the functions or activities performed by processing system 1421 may be storing data in memory 1422 and / or retrieving previously stored data from memory 1422. Base station 1420 may communicate with wireless device 1410 using transmission processing system 1424 and reception processing system 1425. Base station 1420 may include one or more antennas 1426 for accessing air interface 1470. Processing system 1421 may implement Layer 14 and Layer 3 OSI functions. Transmission processing system 1424 and reception processing system 1425 may implement Layer 1 OSI functions to perform downlink data transmission and uplink data reception, respectively.

[0362] Base station 1420 may include interface system 1427. Interface system 1427 may communicate with one or more units of the core network via interface 1480. Interface 1480 may be wired and / or wireless, and interface system 1427 may include one or more components adapted for communication via interface 1480. Figure 14 In this configuration, interface 1480 connects base station 1420 to a single CN deployment 1430; however, it will be understood that wireless device 1410 can communicate with any number of CN deployments via interface 1480, and CN deployment 1430 can communicate with any number of base stations via interface 1480. Base station 1420 may include one or more other elements 1429 similar to one or more other elements 1419.

[0363] CN deployment 1430 may include one or more network functions (NFs). For example, CN deployment 1430 may include similar to Figure 1The AMF and / or UPF depicted herein. CN deployment 1430 may include elements similar to those of wireless device 1410 and base station 1420 as described above. CN deployment 1430 may include processing system 1431 and memory 1432. Memory 1432 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1432 may include instructions 1433. Processing system 1431 may process and / or execute instructions 1433. Processing and / or execution of instructions 1433 may cause processing system 1431 to perform one or more functions or activities. Memory 1432 may include data (not shown). One of the functions or activities performed by processing system 1431 may be storing data in memory 1432 and / or retrieving previously stored data from memory 1432. CN deployment 1430 may access interface 1480 using interface system 1437. CN deployment 1430 may also use interface system 1437 to access interface 1490. CN deployment 1430 can use interface 1490 to connect with one or more data networks (similar to, for example) Figure 1 The DN and / or one or more other CN deployments described herein include Figure 14 The CN deployment 1430 described herein communicates. The CN deployment 1430 may include one or more other elements 1439.

[0364] CN deployment 1440 may include elements similar to those in CN deployment 1430, as described above. CN deployment 1440 may include a processing system 1441 and a memory 1442. Memory 1442 may include one or more computer-readable media, such as one or more non-transitory computer-readable media. Memory 1442 may include instructions 1443. Processing system 1441 may process and / or execute instructions 1443. Processing and / or execution of instructions 1443 may cause processing system 1441 to perform one or more functions or activities. Memory 1442 may include data (not shown). One of the functions or activities performed by processing system 1441 may be storing data in memory 1442 and / or retrieving previously stored data from memory 1442. CN deployment 1440 may access interface 1490 using interface system 1447. CN deployment 1440 may include one or more other elements.

[0365] Processing systems 1411, 1421, 1431, and / or 1441 may include one or more controllers and / or one or more processors. These controllers and / or processors may include, for example, general-purpose processors, digital signal processors (DSPs), microcontrollers, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) and / or other programmable logic devices, discrete gate and / or transistor logic, discrete hardware components, onboard units, or any combination thereof. Processing systems 1411, 1421, 1431, and / or 1441 may perform signal encoding / processing, data processing, power control, input / output processing, and / or any other functions that enable wireless device 1410, base station 1420, CN deployment 1430, and / or CN deployment 1440 to operate in a mobile communication system.

[0366] Each CN deployment may include one or more network functions. Depending on the context in which the term is used, a network function (NF) can refer to a specific set of functions and / or one or more physical elements (e.g., a processing system and a memory containing instructions that, when executed by the processing system, cause the processing system to perform those functions) that perform those functions. Many different types of NFs exist, and each type of NF can be associated with a different set of functions. Different NFs can be flexibly deployed in different locations (e.g., in different physical core network deployments) or in the same location (e.g., juxtaposed within the same physical core network deployment). Furthermore, a physical CN deployment is not limited to the implementation of NFs. For example, a particular physical CN deployment may also include a base station or a portion thereof and / or a data network or a portion thereof. Therefore, one or more NFs implemented on a particular physical core network deployment can be juxtaposed with one or more non-core elements (including elements of the access network or data network).

[0367] In the example, Figure 15 This is a diagram of the 5G policy and charging control system architecture. A reference architecture for the policy and charging control framework for 5G systems may include one or more of the following network functions: Policy Control Function (PCF), Session Management Function (SMF), User Plane Function (UPF), Access and Mobility Management Function (AMF), Network Exposure Function (NEF), Network Data Analysis Function (NWDAF), Charging Function (CHF), Application Function (AF), and Unified Data Repository (UDR).

[0368] In one example, CHF can support at least one charging method: offline charging, online charging, or converged charging. In one example, offline charging can be a process that simultaneously collects charging information for network resource usage along with the resource usage itself. At the end of this process, a CDR file can be generated by the network and transmitted to the network operator's billing domain (BD) for subscriber billing and / or inter-operator accounting (or additional functions determined by the operator, such as statistical data). The BD typically includes post-processing systems, such as the operator's billing system or billing mediation equipment. In the example conclusion, offline charging can be a mechanism where charging information does not affect the services provided in real time. In one example, online charging can be a process that simultaneously collects charging information for network resource usage along with the resource usage itself, in the same manner as offline charging. The network can then obtain authorization for network resource usage before actual resource usage occurs. In one example, the charging information used in online charging may not necessarily be the same as the charging information used in offline charging. In the example conclusion, online charging can be a mechanism where charging information can affect the services provided in real time and therefore may require direct interaction between the charging authority and network resource usage control. In one example, converged charging can be a process that combines online and offline charging.

[0369] Figure 16 This is an example call flow for PDU session establishment (charged) according to an embodiment of this disclosure. In one example, the UE may initiate a PDU session establishment procedure. The PDU session establishment request may include one or more of the following: PDU session ID, PDU type, SSC mode, user location information, and access technology type information. In response to a message received from the UE, the AMF may select an SMF and send a message to the selected SMF (e.g., a Namf_PDUSession_CreateSMContext request). The SMF may send a response message to the AMF (e.g., a Namf_PDUSession_CreateSMContext response).

[0370] In the examples, the SMF can select a PCF and send a message requesting PCC rules (e.g., an SM policy association establishment request) to the PCF, and the PCF can provide the PCC rules in a response message (e.g., an SM policy association establishment response). In one example, the SMF can create a charge ID for a PDU session and can send a charge data request [initial] message to the CHF to authorize the subscriber to start a session triggered by the initiation of a PDU session charge event. In one example, the CHF can open a CDR for this PDU session and can confirm this by sending a charge data response [initial] to the SMF. In one example, the SMF selects a UPF and can initiate an N4 session establishment / modification procedure with the selected UPF. The SMF can interact with the AMF; in one example, the SMF can send a Namf_Communication_N1N2MessageTransfer message to the AMF, which includes one or more of the following: PDU session ID, QoS profile, CN tunnel information, and S-NSSAI from an allowed NSSAI. In one example, the AMF can interact with the (R)AN and the UE by sending an N2 PDU session request message to the (R)AN, which includes information received from the SMF indicating that the PDU session establishment has been accepted.

[0371] In the example, the (R)AN may send an N2 PDU session response message to the AMF that includes one or more of the following: PDU session ID, N2 SM information (PDU session ID, AN tunnel information, accepted / rejected QFI list), where the tunnel information may correspond to the access network address of the N3 tunnel corresponding to the PDU session. In the example, the AMF may send an Nsmf_PDUSession_UpdateSMContext request message to the SMF, which includes the N2 SM information received from the (R)AN to the SMF. In the example, the SMF may initiate an N4 session modification procedure with the UPF. The SMF may provide the UPF with the AN tunnel information and the corresponding forwarding rules. The UPF may send a response message to the SMF. In one example, the SMF may request quotas from the CHF, for example, a "Start Service Data Stream" event may require quotas from the CHF. The SMF may send a message to the CHF (e.g., Charged Data Request [Update]). As an example, for online charging or converged charging, the SMF can request quotas from the CHF when the allocated quota is consumed or when a requested quota is triggered.

[0372] In one example, the UPF can report resource usage of a PDU session to the SMF. As another example, the UPF can report the wireless device's resource usage to the SMF by enforcing charging control rules, and the SMF can send a message to the CHF including resource usage information received from the UPF (e.g., a charge data request [update]). In one example, the CHF can update the CDR for this PDU session. The CHF can acknowledge the SMF by sending a charge data response message. In another example, the SMF can send an Nsmf_PDUSession_UpdateSMContext response message to the AMF.

[0373] Figure 17 This is a diagram of an exemplary communication system architecture. Figure 17 The architecture could be a future communication system, such as a 6G communication system. Example next-generation communication systems could include at least one of the following: wireless devices (e.g., Figure 17 UE in the network, access network (e.g., Figure 17 The (R)AN, control plane functions, user plane functions, AUTH / subscription data functions, charging functions, application server / application function (AF), and / or data network. In the example, the control plane function may include access and mobility management functions. In the example, the control plane function may include session management functions. In the example, the control plane function may include policy and charging control functions. In the example, the receiver may be co-located with the application server / AF. In the example, the receiver may be deployed independently and may be connected to the application server / AF. In the example, the receiver may be a control function of an application. In the example, the receiver may be a second UE communicating with the UE. In the example, the application server / AF / receiver may be in the data network. In the example, the application server / AF / receiver may be outside the data network but connected to it.

[0374] In the examples, holographic display technology has made significant progress in recent years, from light field displays to various types of head-mounted displays (HMDs). Holographic applications can become a reality when the science and technology of constructing and presenting holograms are well understood. These applications may involve not only the local presentation of holograms but also networking aspects, particularly the ability to transmit and stream holographic data from remote sites, known as "holographic communications" (HTC). HTC is more than just a technological approach; it has many potential applications. For example, holographic telepresence could allow remote participants to be projected into a room as a holographic presentation. Conversely, immersive holographic spaces could present artifacts from a distance into a room, thus presenting a local user to a distant location. Remote troubleshooting and maintenance applications could allow technicians in remote and hard-to-reach locations, such as on an oil rig or inside a space probe, to interact with a holographic presentation of a project. Holographic signs presenting centrally managed and distributed holographic content could be a natural next step towards digital signage. Training and education applications could provide remote students with the ability to engage with subjects and other students to actively participate in the classroom. Furthermore, the possibilities are numerous in the realm of immersive gaming and entertainment. For HTC to become a reality, future networks will need to address multiple challenges. Because the transmission of high-quality holograms involves vast amounts of data, they may require extremely high bandwidth. The quality of a hologram may involve not only color depth, resolution, and frame rate in the video, but also the transmission of volumetric data from multiple viewpoints to account for the observer's tilt, angle, and position offset relative to the hologram ("six degrees of freedom"). Streaming the underlying volumetric data and image arrays may impose additional synchronization requirements to ensure a smooth viewing transition for the user.

[0375] Beyond the streaming of the holographic information itself, some applications can also combine holographic images with data from other streams. For example, a holographic avatar might be able to combine a holographic image with its avatar. This allows an entity to not only be projected or presented from a remote site, but also to receive feedback from that remote viewpoint. For instance, video and audio streams can be derived from the viewpoint of the projected hologram. This can be achieved by overlaying the hologram onto corresponding cameras, microphones, or other sensors. Achieving this may require tight synchronization across multiple data streams, but the result will be applications that provide a more realistic sense of user interaction.

[0376] The second set of expansions might involve combining HTC with haptic networking applications, allowing users to “touch” holograms. This could open up new possibilities for applications such as those mentioned above for training and remote repair. Hhaptic networking applications may impose ultra-low latency requirements on the underlying network (to provide accurate haptic feedback), especially for mission-critical applications such as remote surgery, where any loss is unacceptable. Coupling haptic networking with HTC could introduce additional high-precision synchronization requirements to ensure all disparate data streams are properly coordinated. When the discussion involves not only optical (video, holograms) and acoustic (audio) senses but also haptic (tactile) networking applications, a question arises: why stop there; what about other senses? In fact, the involvement of olfactory and gustatory senses may make sense to create a fully immersive experience. Unlike vision and hearing, smell and taste might be considered “lower” senses. They may not typically direct attention or guide human activity but are more likely to be associated with sensation and emotion. These are “proximal senses” because their perception may involve a direct (chemical) reaction between the perceived reagent and the receptor. In contrast, remote senses (hearing and vision) may allow perception from distant sources, transmitting artifacts via waves rather than chemical or physical reactions. The fact that chemical reactions may be involved presents a significant hurdle to overcome: how to construct effective actuators. Some limited success has been achieved using “digital lollipops,” devices inserted into the mouth that deliver small electrical currents and temperature differences to the papillae of the tongue (taste sensors) to mimic sensations such as sour, salty, or sweet. Smell may pose an even more challenging problem. Some researchers have proposed “transcranial stimulation,” such as a set of electromagnets (e.g., integrated into headphones), to deliver stimulation to areas of the brain responsible for generating sensory sensations.

[0377] Compared to the internet industry, the food industry may be more interested in breakthroughs in this area. For example, the ability to generate "digital sweetness" could foreshadow the ability to reduce the use of sugar or artificial sweeteners. While a real breakthrough in actuators for conveying digital smell and taste seems far off at this point, assuming these hurdles can be overcome, there are clearly interesting potential networking applications. For example, distance learning solutions and digital advertising could leverage the fact that association with smell and taste can improve memory retention. Digital experiences could be enhanced, especially since smell and taste can evoke or amplify emotions. For example, certain images could be associated with a particular odor. Cloud-based medical solutions could generate bitterness from a remote location to prevent the ingestion of specific foods as part of a dietary plan at a specific time. In contrast to the actuator problem, the demands imposed on the network by sensing applications can be reasonably and directly supported. To transmit taste and smell data, transmitting data that is actually in contact with the taste or smell receptors—the taste and smell themselves, rather than the taste and smell emitted by any of the many objects in the environment. For example, to transmit a specific taste in a scene, it might not be necessary to transmit the potential taste of every single “pixel” of every object. This may differ from vision, where every object in a scene reflects light as perceived by the end user. While additional factors, such as texture, may influence the perception of taste, the amount of “taste” data that needs to be transmitted is likely significantly less than that required for image communication, given that the number of receptors on the tongue (approximately 8,000) is about four orders of magnitude less than the number of receptors on the retina of the eye (approximately 150 million). Furthermore, since detecting taste in the human body can take up to a second, there is no particular requirement to support ultra-low latency. Similar considerations apply to odor data, although the latency involved in detecting odors by a human is likely to be much lower in reality.

[0378] Current networks offer guarantees of bandwidth and reliability. Bandwidth is likely obvious, as any information carried over the network can be packaged and consume transmission medium capacity. Support for time precision in data delivery can be a fundamental communication service provided by the network. Basic time-engineered services may exist in the following ways: Time-bound services can provide data a priori for real-time applications, allowing for time-constrained packet arrival, e.g., packets can arrive before a specific time. Typical multimedia applications might buffer data for about one hundred milliseconds, but in industrial settings, the feedback control loop response from controller to field unit might be less than ten milliseconds. Both cases are similar because late-arriving packets may be useless, and the behavior may require a finite arrival time. To understand the relevance of time-constrained delivery, compare it to email or web-based services: slow performance leads to a degraded experience, but the data may still be relevant. Just-in-time services may expect data to arrive at a specific time, allowing only very small discrepancies. Just-in-time service guarantees can be provided by precise time with the smallest resolution of measurable time (approximately one millisecond). For example, when several operations are quasi-synchronous, a set of jobs can operate in the order determined by the precise time of each job. This may be particularly relevant to security response applications, such as mobile autonomous objects (cars, drones), where timely service delivery can lead to unpredictable outcomes, but on-time service ensures precise control over system behavior. Financial market sectors may require absolute timestamps to establish fairness in trading operations. Coordination services may require the timely delivery of packets from multiple streams (from the same source or from multiple sources). For example, fully perceptual-enabled applications can generate different sensory experiences on separate streams. Generally, smell and touch do not have the same sensitivity as video, but they can still be synchronized in terms of visual presentation to provide a near-realistic experience.

[0379] In existing technologies, network entities (e.g., base stations or UPFs) can receive multiple service data streams and / or packet streams transmitted between one or more UEs and an application server / receiver. If the network entity is overloaded and / or congested, it can drop packets from one of the multiple streams (e.g., multiple service data streams and / or multiple packet streams). Additionally or alternatively, the network entity can delay the scheduling of one of the multiple streams. In the case of communication with multiple streams between one or more UEs and an application server / receiver (e.g., holographic communication (HTC)), each of the multiple streams must be synchronized. If the multiple streams are not received synchronously, attempts to reconstruct the application (e.g., video, images, motion, etc.) may fail.

[0380] The exemplary embodiments of this disclosure can provide enhanced mechanisms to support the synchronization of multiple service data streams / packet streams in a network (e.g., a 6G communication network and / or a future network). As described above, overloaded network entities (e.g., base stations and / or UPFs) may drop data or delay the transmission of data associated with a particular service data stream or packet stream. If a delayed or dropped stream is associated with an application (e.g., HTC) that relies on the synchronized reception of multiple streams, the application may fail.

[0381] Exemplary embodiments of this disclosure can provide enhanced mechanisms to support synchronization requests and / or executions of multiple data streams (e.g., Serving Data Streams (SDF), packet streams, etc.) between a network and / or its various network entities for one or more wireless devices and application functions (e.g., application servers, application receivers, etc.). Exemplary embodiments of this disclosure can provide enhanced mechanisms to synchronously support the scheduling of multiple data streams. For example, a first network function (NF) can receive parameters indicating a request for synchronization of multiple data streams. The first NF may be a control plane function (e.g., SMF, PCF, etc.). Parameters (e.g., application functions associated with the multiple data streams, wireless devices associated with one or more of the multiple data streams, etc.) can be received from, for example, network participants associated with the multiple data streams. Based on these parameters, the first NF can support synchronization of one or more other network entities (e.g., base stations, base station central units (BS-CU), second NFs (e.g., UPF), etc.). In exemplary embodiments of this disclosure, the first NF can indicate the synchronization of multiple data streams to network entities. This indication may be, for example, a user plane rule, an indication of a synchronization request, a Stream Synchronization Request Indication (FSRI), etc. According to various implementation schemes, a network entity can receive this instruction. Based on this instruction, the network entity can perform synchronization of multiple data streams (e.g., synchronized scheduling of packets associated with multiple data streams).

[0382] Depending on the implementation, when faced with overload, a network entity may attempt to avoid dropping and / or delaying any of the flows associated with the synchronization request. For example, the network entity may determine to process each of the multiple flows associated with the synchronization request in a similar manner. If the network entity is overloaded, it may synchronously deliver all the multiple flows while dropping / delaying other selected flows. Alternatively, the network entity may drop data associated with each of the multiple flows to reduce congestion, or delay each of the multiple flows to reduce congestion.

[0383] Figure 18An exemplary mobile communication network supporting the synchronization of multiple service data streams is illustrated. In the example, multiple UEs can send multiple service data streams and / or packet streams to an application server / receiver via the communication network (e.g., a 6G communication network) in the uplink direction, and these multiple service data streams and / or packet streams may need to be synchronized by the communication network. In the example, a service data stream can be an aggregated set of packet streams carried by user plane functions and / or base stations that match a service data stream template. In the example, a packet stream can be a specific user data stream originating from and / or destined for a UE. In the example, a service data stream template can be a set of service data stream filters. In the example, a service data stream filter can be a set of packet stream header parameter values / ranges used to identify one or more packet streams in the user plane functions, base stations, UEs, and / or application server / receiver. In the example, a QoS stream can be the granularity of QoS differentiation in a session (e.g., a PDU session, a service data session, etc.) used for QoS forwarding processing in a communication system (e.g., 5G, 6G, etc.). A QoS stream ID (QFI) can be used to identify a QoS stream. For example, all traffic mapped to the same QoS flow (e.g., the same QFI) can receive the same forwarding processing (e.g., scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.).

[0384] For example, the communication network may include a base station, a first network function (e.g., a control plane function), and / or a second network function (e.g., a user plane function). For example, UE 1 may send SDF 1 to the application server / receiver via the base station and the second network function (e.g., the user plane function); UE 2 may send SDF 2 to the application server / receiver via the base station and the second network function; UE 3 may send SDF 3 to the application server / receiver via the base station and the second network function. UE 1 may include camera 1, and SDF 1 may include video data 1. UE 2 may include camera 2, and SDF 2 may include video data 2. UE 3 may include camera 3, and SDF 3 may include video data 3. SDF 1, SDF 2, and SDF 3 may be concurrent streams / data streams that need to be synchronized by the communication network. SDF 1, SDF 2, and SDF 3 may each be part of an application (e.g., a holographic view), and the application server / receiver can reconstruct the application using SDF 1, SDF 2, and SDF 3. In this example, the application server may be the receiver. In this example, the application server may be connected to the receiver. The receiver can be an application's control / management function. The receiver can be a wireless device. In the example, the application server / receiver can send multiple SDFs to multiple UEs via the communication network in the downlink direction, and these multiple SDFs need to be synchronized by the communication network.

[0385] Figure 19 An exemplary mobile communication network supporting the synchronization of multiple service data streams is illustrated. In the example, there may be data sources (e.g., cameras, sensors) connected to a wireless device (UE). Each data source can send different data streams to the UE via a near-field communication network (e.g., Bluetooth, Wi-Fi, etc.). The UE can map the different data streams to different SDFs and can send the different SDFs to an application server / receiver (e.g., a holographic communication (HTC) server) via the communication network (e.g., base station and / or user plane functions) in the uplink direction. The HTC server can perform holographic image reconstruction. In the example, the application server / receiver can send multiple SDFs to the UE via the communication network in the downlink direction, and the multiple SDFs need to be synchronized by the communication network. The UE can map the multiple SDFs to different data streams and send them to different data sources. The procedure for multiple SDFs can be similar to... Figure 18 .

[0386] Figure 20This can be an exemplary invocation flow that may include one or more actions. In the example, the UE may send a first message to a first network function (FNF). In the example, the UE may send a first message to the first network function via a base station. In the example, the first network function may be a control plane function. In the example, the first message may request a UE's Service Data Session (SDS). In the example, the first message may be a registration message. In the example, the first message may be an attachment request message. In the example, the first message may be a session request message. In the example, the first message may be a service request message. In the example, the first message may include at least one of the following: UE identity, Service Data Session identifier, Service Data Session type, PLMN identifier, and / or user location information. In the example, the first message may include at least one of the following information elements: a flow synchronization request indication, flow information for multiple SDFs / multiple packet flows / QoS flows, a Holographic Communication (HTC) network slice for the request of multiple SDFs / multiple packet flows / QoS flows; HTC Data Network Names (DNNs) for multiple SDFs / multiple packet flows / QoS flows, and / or timestamp information for multiple SDFs / multiple packet flows / QoS flows. A flow synchronization request indication can indicate a request for synchronization of multiple Service Data Streams (SDFs) / multiple packet streams / QoS streams. For example, a flow synchronization request indication can indicate a request for synchronization of one or more QoS streams, where one QoS stream may include multiple Service Data Streams. In the example, the flow information for the multiple SDFs / multiple packet streams / QoS streams may include flow identifiers for the multiple SDFs / multiple packet streams and / or flow filter information for the multiple SDFs / multiple packet streams. For example, the flow information for the multiple SDFs / multiple packet streams / QoS streams may include one or more flow identifiers for one or more QoS streams and / or flow filter information for one or more QoS streams. In the example, the flow filter information may include an IP packet filter set and / or an Ethernet packet filter set. For example, the IP packet filter set may include at least any combination of the following: source / destination IP address or IPv6 prefix, source / destination port number, protocol ID of the protocol above the IP / Next Header Type, Type of Service (TOS) (IPv4) / Traffic Class (IPv6) and mask, flow label (IPv6), security parameter index, and / or packet filter direction.For example, the Ethernet packet filter set may include at least any combination of the following: source / destination MAC address, Ethernet type as defined in IEEE 802.3, customer-VLAN tag (C-TAG) and / or service-VLAN tag (S-TAG) VID field as defined in IEEE 802.1Q, customer-VLAN tag (C-TAG) and / or service-VLAN tag (S-TAG) PCP / DEI field as defined in IEEE 802.1Q, packet filter direction, and / or IP packet filter set where the Ethernet type indicates an IPv4 / IPv6 payload. In the example, a requested HTC network slice may indicate a network slice with an HTC service type. In the example, a requested HTC network slice may indicate that multiple SDFs / multiple packet flows / QoS flows of the requested HTC network slice are requested to be synchronized. In the example, an HTC DNN may indicate that multiple SDFs / multiple packet flows / QoS flows of the DNN are requested to be synchronized. Timestamp information may indicate timestamp information in the SDFs / packet flows / QoS flows sent and / or received by the UE. In the example, timestamp information may include at least one of the following: timestamp type, timestamp size, and / or timestamp position. Timestamp type may indicate at least one of the following: absolute time, relative time, and / or NTP timestamp. Timestamp size may indicate how many octets / bits the timestamp occupies in the packet (e.g., 8 octets, 64 bits). Timestamp position may indicate the position of the timestamp within the packet. For example, the timestamp may be in the IP header (e.g., IP Option 4). For example, the timestamp may be in the Transmission Control Protocol (TCP) header. For example, the timestamp may be at the end of the payload of an Ethernet packet. For example, the timestamp may be at the end of the payload of a TCP / IP packet. For example, the timestamp may be at the end of the payload of an IP packet. In the example, the packet may include at least one header and / or payload. For example, the packet may be an Ethernet packet. For example, the packet may be an IP packet. For example, the packet may be a TCP / IP packet. For example, the packet may be a UDP / IP packet. Figure 21 An exemplary diagram illustrating a service data session establishment request message body according to an embodiment of this disclosure.

[0387] In response to a message received from the UE, a first network function may take one or more actions. In exemplary actions, based on information from the first message received from the UE and / or user subscription information and / or local policies, the first network function may determine policies and charging control rules for multiple SDFs / multiple packet flows / QoS flows. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, an HTC DNN, and / or timestamp information, the first network function may determine at least one policy and charging control rule. In the example, at least one policy and charging control rule may be applied to a service data session. In the example, at least one policy and charging control rule may be applied to the UE. In the example, at least one policy and charging control rule may be applied to a requested HTC network slice. In the example, at least one policy and charging control rule may be applied to an HTC DNN. In the example, at least one policy and charge control rule may include at least one of the following: a stream synchronization request indication, time configuration information, at least one charge control rule; at least one policy control rule, including at least one QoS control rule and / or at least one gating control rule; at least one usage monitoring control rule; at least one application detection and control rule; at least one traffic redirection control rule; and / or at least one service data stream detection information (e.g., a service data stream template).

[0388] In the example, at least one charging control rule can be used for charging control and may include at least one of the following: an information element indicating the charging method / charging type, an information element indicating the charging rate, and / or an information element indicating the CHF identifier or address. The charging method / charging type may include at least one of the following: online charging, offline charging, or converged charging. In the example, at least one policy control rule can be used for policy control, wherein at least one QoS control rule can be used for QoS control, and at least one gating control rule can be used for gating control. In the example, at least one QoS control rule can be used for QoS on authorized service data flows. In the example, at least one gating control rule can be used to drop packets that do not match any service data flow that is not matched with the gating control rule and / or associated policy and charging control rules. In the example, at least one QoS control rule may include a QoS category identifier (e.g., QCI, 5QI), a priority (e.g., ARP), and / or at least one bandwidth value for the uplink and / or downlink service data flow / packet flow / QoS flow. In the example, at least one usage monitoring control rule can be used to monitor quantity and time usage and report the cumulative usage of network resources. In the example, at least one application detection and control rule may include detecting specified application traffic, reporting the start or stop of application traffic to the PCF, and requesting specified execution and charging actions. In the example, at least one traffic redirection control rule may be used to activate / deactivate traffic redirection policies to redirect subscriber traffic to appropriate carrier or third-party service functions within the (S)Gi-LAN (e.g., NAT, anti-malware, parent control, DDoS protection). In the example, at least one service flow detection information may include a list of service flow filters or application identifiers that reference the corresponding application detection filters to detect service flow. In the example, at least one service flow detection information may include a combination of traffic patterns of Ethernet PDU traffic. In the example, based on flow information, a first network function may determine at least one service flow detection information. For example, at least one service flow detection information may include filter information. In the example, based on a flow synchronization request indication, a first network function may determine at least one policy control rule and / or at least one QoS control rule. For example, at least one QoS control rule may be applied to / associated with SDF 1, SDF 2, and / or SDF 3, and a first network function may determine the same QoS category identifier (e.g., 5QI) and / or the same priority (e.g., ARP) for SDF 1, SDF 2, and / or SDF 3. In the example, a flow synchronization request indication in at least one policy and charge control rule may indicate that the service data flow / packet flow / QoS flow associated with at least one policy and charge control rule needs to be synchronized.For example, if a service data stream / packet stream / QoS stream can be matched with at least one service data stream detection information of at least one policy and charging control rule, then the service data stream / packet stream / QoS stream needs to be synchronized. In the example, a first network function can determine the flow synchronization of multiple service data streams / packet streams / QoS streams for multiple policy and charging control rules. For example, SDF 1, SDF 2, and SDF 3 are associated with policy and charging control rule 1 (e.g., policy and charging control rule 1 applies to SDF 1, SDF 2, and SDF 3), and SDF 4, SDF 5, and SDF 6 are associated with policy and charging control rule 2 (e.g., policy and charging control rule 2 applies to SDF 4, SDF 5, and SDF 6), the first network function can determine the flow synchronization of SDF 1, SDF 2, SDF 3, SDF 4, SDF 5, and / or SDF 6.

[0389] In the example, the first network function can determine timestamp configuration information based on timestamp information. In the example, the timestamp configuration information can indicate the timestamp configuration information for service data streams / packet streams / QoS streams used for synchronization. The timestamp configuration information can include at least one of the following: timestamp type, timestamp size, timestamp position, and / or the accepted time difference between SDF / packet streams / QoS streams used for synchronization. For example, the accepted time difference could be 2 milliseconds, SDF 1's timestamp is 1000, and SDF 2's timestamp is 1001. Because the time difference between SDF 1 and SDF 2 is 1 millisecond, which is less than the accepted time difference, SDF 1 and SDF 2 can then be synchronized.

[0390] In an exemplary operation, the first network function may select a CHF based on a Stream Synchronization Request Indication, Stream Information, a requested HTC network slice, an HTC DNN, and / or at least one policy and charging control rule. For example, the first network function may determine the CHF based on the requested HTC network slice, such that the selected CHF supports charging for the HTC network slice. In an exemplary operation, the first network function may send a message (e.g., a Charged Data Request) to the CHF, the message including at least one of the following: a Stream Synchronization Request Indication, Stream Information, a requested HTC network slice, an HTC DNN, a Service Data Session Identifier; UE identity, Service Data Session Type, a PLMN identifier, and / or user location information.

[0391] In response to receiving a chargeable data request message, the CHF can determine the quota for the service data session and / or SDF / packet flow / QoS flow based on information received from the first network function. In an example, the quota may include at least one of the following: an authorized unit; a time quota threshold; or a quantity quota threshold. In an example, based on a flow synchronization request indication, flow information, a requested HTC network slice, and / or an HTC DNN, the CHF can determine the higher authorized unit for the service data session and / or SDF / packet flow / QoS flow. The CHF may send a response message (e.g., a chargeable data response) to the first network function, including the quota, the service data session identifier, the UE identity, and / or the flow information for the SDF / packet flow / QoS flow.

[0392] In an exemplary operation, a first network function may determine at least one user plane rule based on a first message, at least one policy and charging control rule, and / or quota. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, an HTC DNN, at least one policy and charging control rule, and / or quota, the first network function may determine at least one user plane rule. In the example, at least one user plane rule may be applied to a service data flow / packet flow / QoS flow. In the example, at least one user plane rule may be applied to a service data session. In the example, at least one user plane rule may be applied to a UE. In the example, at least one user plane rule may be applied to a requested HTC network slice. In the example, at least one user plane rule may be applied to an HTC DNN. In the example, at least one user plane rule may include at least one of the following: a flow synchronization request indication, time configuration information, at least one packet detection rule, at least one forwarding action rule, at least one QoS enforcement rule, and / or at least one usage reporting rule.

[0393] In the example, at least one packet detection rule may include data / traffic packet detection information, such as one or more matching fields, to which an incoming packet matches, and may apply other user plane rules (e.g., at least one forwarding action rule, at least one QoS enforcement rule, and / or at least one usage reporting rule) to the data / traffic packets matching the packet detection rule. In the example, at least one forwarding action rule may include application action parameters that may instruct a second network function (e.g., a user plane function) whether to forward, copy, drop, or buffer data / traffic packets, respectively. In the example, at least one usage reporting rule may be used to measure network resource usage in terms of traffic data volume, duration (i.e., time), and / or events, according to a measurement method in at least one usage reporting rule. In the example, at least one QoS enforcement rule may contain an instruction requesting a user plane function to perform QoS enforcement on user plane traffic. In the example, a first network function may determine at least one packet detection rule based on at least one service data flow detection information (e.g., service data flow template, flow information). In the example, a first network function may determine at least one forwarding action rule based on at least one policy control rule and / or at least one usage monitoring control rule. In the example, the first network function may determine at least one QoS enforcement rule based on at least one policy control rule (e.g., at least one QoS control rule). In the example, the first network function may determine at least one usage reporting rule based on at least one usage monitoring control rule and / or quotas.

[0394] In the example, a flow synchronization request indication in at least one user plane rule can indicate that the service data flow / packet flow / QoS flow associated with at least one user plane rule needs to be synchronized. For example, if the service data flow / packet flow / QoS flow can match at least one packet detection rule, then the service data flow / packet flow / QoS flow needs to be synchronized. In the example, a first network function can determine the flow synchronization of multiple service data flows / packet flows / QoS flows for multiple user plane rules. For example, SDF 1, SDF 2, and SDF 3 are associated with user plane rule 1 (e.g., user plane rule 1 applies to SDF 1, SDF 2, and SDF 3), and SDF 4, SDF 5, and SDF 6 are associated with user plane rule 2 (e.g., user plane rule 2 applies to SDF 4, SDF 5, and SDF 6), and the first network function can determine the flow synchronization of SDF 1, SDF 2, SDF 3, SDF 4, SDF 5, and / or SDF 6.

[0395] In an exemplary operation, the first network function may select a second network function (e.g., a user plane function) based on a stream synchronization request indication, stream information, a requested HTC network slice, an HTC DNN, at least one policy and charging control rule, and / or at least one user plane rule. For example, the first network function may determine the second network function based on a stream synchronization request indication; for example, the selected second network function may support stream synchronization. Alternatively, the first network function may determine the second network function based on a requested HTC network slice; for example, the selected second network function may support HTC network slices.

[0396] In an exemplary action, a first network function may send a message (e.g., a user plane session request) to a second network function. The user plane session request message may indicate a request for synchronization of service data streams / packet streams / QoS streams. For example, the user plane session request message may include at least one information element: a stream synchronization (request) indication, at least one user plane rule, and / or time configuration information. The stream synchronization (request) indication in the user plane session request message may indicate that the service data streams / packet streams / QoS streams associated with the user plane session request message need to be synchronized. For example, the user plane session request message may include user plane rule 1 and user plane rule 2, where user plane rule 1 may include packet detection rule 1, and user plane rule 2 may include packet detection rule 2. The stream synchronization (request) indication in the user plane session request message may indicate that the SDF / packet stream / QoS stream matching packet detection rule 1 needs to be synchronized with the SDF / packet stream / QoS stream matching packet detection rule 2. For example, a user plane session request message may include user plane rule 1 and user plane rule 2, SDF 1, SDF 2, and SDF 3 associated with user plane rule 1 (e.g., user plane rule 1 applies to SDF 1, SDF 2, and SDF 3), and SDF 4, SDF 5, and SDF 6 associated with user plane rule 2 (e.g., user plane rule 2 applies to SDF 4, SDF 5, and SDF 6). A stream synchronization (request) indication in the user plane session request message may indicate that SDF 1, SDF 2, SDF 3, SDF 4, SDF 5, and / or SDF 6 need to be synchronized. In response to a message received from a first network function, a second network function may install at least one user plane rule and send a response message (e.g., a user plane session response) to the first network function.

[0397] In an exemplary action, a first network function may send a message (e.g., a Service Data Session Response) to a base station (e.g., (R)AN). The Service Data Session Response message may indicate acceptance of synchronization of the service data stream / packet stream / QoS stream. For example, the Service Data Session (SDS) Response message may include at least one information element: a stream synchronization (acceptance) indication, time configuration information, an SDS identifier, at least one QoS control rule, at least one packet detection rule, CN tunnel information, accepted network slice, UE IP address, HTC DNN and / or header compression configuration. In the example, the stream synchronization (acceptance) indication may indicate that the network has accepted the request for synchronization of the service data stream / packet stream / QoS stream. In the example, the stream synchronization (acceptance) indication may indicate that the network requests synchronization of the service data stream / packet stream / QoS stream. The SDS identifier may indicate an identifier for the service data session. At least one packet detection rule may be used by the (R)AN to detect incoming packets, and if the incoming packet matches the at least one packet detection rule, at least one QoS control rule may be applied. In the example, at least one packet detection rule may include stream information. In the example, at least one QoS control rule may include stream information. CN tunnel information may include the core network address corresponding to the service data session (e.g., a second network address, a user plane function address). The first network may assign a UE IP address and send the UE IP address to the (R)AN and / or the UE. Header compression configuration may include configuration information for header compression performed by the (R)AN and / or the UE. Accepted network slices may include accepted / allowed network slices (e.g., HTC network slices).

[0398] In response to a message received from the first network function, (R)AN may take one or more actions. In an exemplary action, (R)AN may take actions such as... Figure 26 The actions described herein. In an exemplary action, based on a flow synchronization (acceptance) indication, time configuration information, an SDS identifier, at least one QoS control rule (e.g., QoS parameters and / or flow information), and / or at least one packet detection rule (e.g., flow information), (R)AN can determine the resources for the SDF / packet flow / QoS flow that needs to be synchronized. For example, based on a flow synchronization (acceptance) indication and / or at least one QoS control rule, (R)AN can allocate resources for all SDF / packet flow / QoS flows that need to be synchronized. For example, (R)AN can reject a request from a first network function, for example by sending a reason value to the first network function indicating that (R)AN cannot allocate resources for any of the SDF / packet flow / QoS flow. In the example, (R)AN can allocate resources for the DRB associated with the SDF / packet flow / QoS flow.

[0399] In an exemplary action, the (R)AN may send a message (e.g., a Service Data Session Response) to the UE, which may include one or more information elements received from a first network function. For example, the Service Data Session Response message sent to the UE may indicate acceptance of synchronization of a service data stream / packet stream / QoS stream. For example, the Service Data Session (SDS) Response message sent to the UE may include at least one of the following: a stream synchronization (acceptance) indication, an SDS identifier, at least one QoS control rule, at least one packet detection rule, CN tunnel information, accepted network slice, UE IP address, HTCDNN and / or header compression configuration.

[0400] In response to a message received from the (R)AN, the UE can send data packets to the (R)AN. For example, the data packet can be at least one of multiple SDFs. For example, the data packet can be at least one of multiple packet streams. For example, the data packet can be a QoS stream. In the example, the data packet sent by the UE can include a timestamp. For example, the timestamp can indicate the time the UE sent the data packet. In the example, the timestamp can be an absolute time (e.g., the current time). In the example, the timestamp can be a relative time; for example, the timestamp can include a second number since January 1, 1900. For example, the timestamp can be a Network Time Protocol (NTP) timestamp. In the example, the timestamp can be in the IP header (e.g., IP Option 4). In the example, the timestamp can be in the Transmission Control Protocol (TCP) header. In the example, the timestamp can be at the end of the payload of an Ethernet packet. In the example, the timestamp can be at the end of the payload of a TCP / IP packet. In the example, the timestamp can be at the end of the payload of an IP packet.

[0401] In response to a data packet received from the UE, and / or in response to a message received from a first network function, the (R)AN can perform data packet synchronization by synchronizing (e.g., simultaneously) scheduling data packets based on a flow synchronization (acceptance) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or timestamps in the data packets. For example, the (R)AN can receive SDF 1, SDF 2, and / or SDF 3 from the UE. SDF 1 may include timestamp 1, SDF 2 may include timestamp 1 + Δt, and SDF 3 may include timestamp 1 – Δt, for example, Δt is 2 milliseconds. The (R)AN can detect that SDF 1, SDF 2, and / or SDF 3 match at least one packet detection rule. Based on the flow synchronization (acceptance) indication and / or time configuration information (e.g., the acceptance time difference between SDFs is 1 millisecond), the (R)AN can synchronize (e.g., simultaneously) schedule SDF 1, SDF 2, and / or SDF 3. Based on CN tunnel information, (R)AN can synchronously send / forward SDF, SDF 2 and / or SDF 3 to a second network function (e.g., user plane function). Figure 27A This is an exemplary diagram depicting a base station performing synchronization of multiple service data streams according to an embodiment of the present disclosure.

[0402] In the example, in response to a data packet received from (R)AN, and / or in response to a message received from the first network function, the second network function may execute at least one user plane rule. In the example, the second network function may execute at least one packet detection rule by matching user data / traffic packets with service flow templates (e.g., service flow filters and / or application identifiers) and / or flow information, and may apply other user plane rules (e.g., at least one forwarding action rule, at least one QoS enforcement rule, and / or at least one usage reporting rule) to data / traffic packets matched with at least one packet detection rule. In the example, the second network function may execute at least one forwarding action rule by forwarding, copying, dropping, or buffering data / traffic packets, respectively. In the example, the second network function may redirect traffic to the operator's web portal. In the example, based on the measurement method in at least one usage reporting rule, the second network function may execute at least one usage reporting rule by measuring network resource usage in terms of traffic volume, duration (i.e., time), and / or events. When a quota / threshold is reached and / or an event and / or another trigger is met, the second network function may report network resource usage to the first network function. In the example, the second network function can execute at least one QoS enforcement rule by applying at least one QoS parameter to a service data stream / packet stream / QoS stream. The at least one QoS parameter can include at least one of the following: 5QI, ARP, MBR, GBR. In the example, the second network function can execute at least one QoS enforcement rule by applying the session AMBR and / or the default 5QI / ARP combination to a service data session.

[0403] In the example, in response to packets received from (R)AN and / or messages received from the first network function, the second network function can perform packet synchronization by synchronously (e.g., simultaneously) scheduling packets based on at least one user plane rule and / or timestamps in the packets. For example, the second network function can receive QoS flow 1 and / or QoS flow 2 from (R)AN. QoS flow 1 may include SDF 1, SDF 2, and / or SDF 3, and QoS flow 2 may include SDF 4, SDF 5, and / or SDF 6. SDF 1 may include timestamp 1, SDF 2 may include timestamp 1 + Δt, and SDF 3 may include timestamp 1 – Δt. SDF 4 may include timestamp 1, SDF 5 may include timestamp 1 + Δt, and SDF 6 may include timestamp 1 – Δt. For example, Δt is 2 milliseconds. The second network function can detect packet detection rule 1 where SDF 1, SDF 2, and / or SDF 3 match at least one user plane rule, and can detect packet detection rule 2 where SDF 4, SDF 5, and / or SDF 6 match at least one user plane rule. Based on a stream synchronization (request) indication and / or time configuration information (e.g., a 1-millisecond time difference between SDFs), the second network function can synchronously (e.g., simultaneously) schedule SDF 1, SDF 2, SDF 3, SDF 4, SDF 5, and / or SDF 6. The second network function can synchronously send / forward SDF 1, SDF 2, SDF 3, SDF 4, SDF 5, and / or SDF 6 to the receiver / server / AF. Figure 28A This is an exemplary diagram depicting a user plane function that performs synchronization of multiple service data streams according to an embodiment of this disclosure. In response to receiving a data packet (e.g., SDF / packet stream / QoS stream) from a second network function, the receiver / server / AF can take one or more actions. In an exemplary action, the receiver / server / AF can reconstruct an application (e.g., a holographic view, holographic video) using the received data packet (e.g., SDF / packet stream / QoS stream).

[0404] In an exemplary operation, the receiver / server / AF may send application packets (e.g., SDF / packet stream / QoS stream) to the UE via a second network function and / or (R)AN. For example, the receiver / server / AF may send video / audio packets to the UE. For example, the receiver / server / AF may send control signaling to the UE that can change the angle of the camera / sensor. For example, the receiver / server / AF may send an acknowledgment packet (e.g., TCP ACK) to the UE. In the example, the application packets sent by the receiver / server / AF may include time information. In the example, the packets sent by the receiver / server / AF may include a timestamp. For example, the timestamp may indicate the time the receiver / server / AF sent the packets. In the example, the timestamp may be an absolute time (e.g., current time). In the example, the timestamp may be a relative time; for example, the timestamp may include a second number since January 1, 1900. For example, the timestamp may be a Network Time Protocol (NTP) timestamp. In the example, the timestamp may be in the IP header (e.g., IP Option 4). In the example, the timestamp may be in the Transmission Control Protocol (TCP) header. In the example, the timestamp can be at the end of the Ethernet packet payload. In the example, the timestamp can be at the end of the TCP / IP packet payload. In the example, the timestamp can be at the end of the IP packet payload. In response to receiving application packets from the receiver / server / AF, based on at least one user plane rule and / or the timestamp in the application packets, the second network function can perform application packet synchronization by synchronously (e.g., simultaneously) scheduling application packets. The second network function can synchronously send / forward application packets (SDF / packet stream / QoS stream) to (R)AN. Figure 28B This is an exemplary diagram depicting a user plane function that performs synchronization of multiple service data streams according to an embodiment of this disclosure. In response to receiving an application data packet from a second network function, the (R)AN can perform packet synchronization by synchronously (e.g., simultaneously) scheduling the data packets based on a stream synchronization (acceptance) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the application data packet. The (R)AN can synchronously send / forward application data packets (SDF / packet stream / QoS stream) to the UE. Figure 27BThis is an exemplary diagram depicting a base station performing synchronization of multiple service data streams according to aspects of embodiments of this disclosure. In response to receiving an application data packet from the (R)AN, the UE can take one or more actions. For example, when receiving video / audio data packets from a receiver / server / AF, the UE can play video and / or audio. For example, the UE can take actions based on control signaling from the receiver / server / AF, such as changing the angle of a camera / sensor. For example, the UE can send multiple SDFs to multiple cameras / sensors to control some actions of the cameras / sensors. For example, the UE can send multiple SDFs to multiple cameras / sensors to change the angle of the cameras / sensors. In the example, the UE can send multiple SDFs to the cameras / sensors via WiFi, Bluetooth, etc. Figure 22 An exemplary diagram is provided to depict a procedure of a UE according to an embodiment of this disclosure. Figure 23 An exemplary diagram illustrating a procedure for a first network function of an embodiment according to this disclosure. Figure 24 An exemplary diagram illustrating a procedure for a second network function according to an embodiment of the present disclosure.

[0405] Figure 25 This can be an exemplary call flow that may include one or more actions. In the example, such as... Figure 18 As shown, a communication system can have up to three UEs. (Back) Figure 25UE 1 may have established a Service Data Session 1 with a communication network (e.g., (R)AN, a first network function, and / or a second network function), and Service Data Session 1 may include bidirectional (e.g., uplink and / or downlink) SDF 1. UE 2 may have established a Service Data Session 2 with a communication network, and Service Data Session 2 may include bidirectional (e.g., uplink and / or downlink) SDF 2. UE 3 may have established a Service Data Session 3 with a communication network, and Service Data Session 3 may include bidirectional (e.g., uplink and / or downlink) SDF 3. The receiver / server / AF may have application layer signaling (e.g., SIP / SDP) with each of the three UEs respectively. The receiver / server / AF may send messages (e.g., application information provision) to the first network function. The application information provision message may indicate the synchronization of multiple SDFs / multiple packet streams / QoS streams. For example, an application information provision message may include at least one information element: a stream synchronization request indication, stream information for multiple SDFs (e.g., SDF 1, SDF 2, and / or SDF 3) / multiple packet streams / QoS streams, a Holographic Communication (HTC) network slice requesting multiple SDFs / multiple packet streams / QoS streams, HTC Data Network Names (DNNs) for multiple SDFs / multiple packet streams / QoS streams, timestamp information for multiple SDFs / multiple packet streams / QoS streams, an identifier for Service Data Session 1, an identifier for Service Data Session 2, and / or an identifier for Service Data Session 3. The definition / meaning of at least one information element may be similar to that referenced above. Figure 20 The information elements described. For the sake of brevity, further descriptions will not be repeated here.

[0406] In response to a message received from a receiver / server / AF, a first network function may take one or more actions. In exemplary actions, based on application information providing message information and / or user subscription information and / or local policies, the first network function may determine policy and charging control rules for multiple SDF / multiple packet flows / QoS flows. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, HTC DNN, and / or timestamp information, the first network function may determine at least one policy and charging control rule. In the example, at least one policy and charging control rule may be a new policy and charging control rule. In the example, at least one policy and charging control rule may be an updated policy and charging control rule; for example, the first network function may update existing policy and charging control rules based on application information providing message information and / or user subscription information and / or local policies. The procedure and / or content for determining at least one policy and charging control rule may be similar to the above reference. Figure 20 The description includes at least one policy and the procedure and / or content for determining the fee control rules. For the sake of brevity, further descriptions will not be repeated here.

[0407] In an exemplary action, the first network function may determine at least one user plane rule based on at least one policy and charging control rule. In the example, the at least one user plane rule may be a new user plane rule. In the example, the at least one user plane rule may be an updated user plane rule; for example, the first network function may update an existing user plane rule based on at least one policy and charging control rule. The procedure and / or content for determining the at least one user plane rule may be similar to the above reference. Figure 20 The description includes the procedure and / or content for determining at least one user plane rule. For the sake of brevity, further descriptions will not be repeated here.

[0408] In an exemplary action, a first network function may send a message (e.g., a user plane session modification) to a second network function. The user plane session modification message may indicate a request for synchronization of service data flows (e.g., SDF 1, SDF 2, and / or SDF 3) / packet flows / QoS flows. For example, the user plane session modification message may include at least one information element: a flow synchronization (request) indication, at least one user plane rule, time configuration information, an identifier for service data session 1, an identifier for service data session 2, and / or an identifier for service data session 3. In response to the message received from the first network function, the second network function may execute at least one user plane rule. The procedure for executing at least one user plane rule may be similar to the above reference. Figure 20 The description specifies the execution of at least one user plane rule. For the sake of brevity, further details will not be repeated here.

[0409] In an exemplary action, the first network function may send a message (e.g., a service data session modification) to the base station (e.g., (R)AN). The service data session modification message may instruct the synchronization of service data streams (e.g., SDF 1, SDF 2, and / or SDF 3) / packet streams / QoS streams. For example, the service data session modification message may include at least one information element: a stream synchronization indication, time configuration information, an identifier for service data session 1, an identifier for service data session 2, and / or an identifier for service data session 3, at least one QoS control rule, at least one packet detection rule, CN tunnel information, accepted network slices, UE IP address, HTC DNN, and / or header compression configuration. In the example, the stream synchronization indication may indicate a request for synchronization of service data streams / packet streams / QoS streams. In the example, the stream synchronization indication may indicate that the network requests synchronization of service data streams / packet streams / QoS streams. The definition / meaning of at least one information element in the service data session modification message may be similar to that referenced above. Figure 20The description defines / meaning of at least one information element in the service data session response message. For the sake of brevity, further descriptions will not be repeated here.

[0410] In response to a message received from the first network function, (R)AN may take one or more actions. In an exemplary action, (R)AN may take actions such as... Figure 26 The actions described herein. In an exemplary action, (R)AN may send messages (e.g., service data session modification) to UE 1, UE 2, and UE 3 respectively. Service data session modification may include one or more information elements received from the first network function. For example, a service data session modification message sent to the UE may indicate the synchronization of service data streams / packet streams / QoS streams. For example, a service data session modification message sent to the UE may include at least one of the following: stream synchronization indication, service data session 1 identifier / service data session 2 identifier / service data session 3 identifier, at least one QoS control rule, at least one packet detection rule, CN tunnel information, accepted network slice, UE IP address, HTC DNN and / or header compression configuration.

[0411] In response to a message received from the (R)AN, UE 1, UE 2, and / or UE 3 may send (uplink) data packets to the receiver / server / AF. The (uplink) data packets may be processed / forwarded via the (R)AN and / or the second network function. In the example, the receiver / server / AF may send (downlink) application data packets to UE 1, UE 2, and / or UE 3. The (downlink) application data packets may be processed / forwarded via the second network function and / or the (R)AN. The procedures for the UE, (R)AN, second network function, and / or receiver / server / AF may be similar to those described in the reference above. Figure 20 The program is described. For the sake of brevity, further descriptions will not be repeated here.

[0412] Figure 26 This is an exemplary call flow that may include one or more actions. In the example, (for example, see...) Figure 20 and / or Figure 25In response to a message received from the first network function, the first network function may send a message (e.g., a Serving Data Session Response, Serving Data Session Modification) to the (R)AN (e.g., the CU of the (R)AN). The Serving Data Session Response message may include at least one information element: a flow synchronization (acceptance) indication, time configuration information, an SDS identifier, at least one QoS control rule (e.g., QoS parameters and / or flow information), at least one packet detection rule (e.g., flow information), CN tunnel information, accepted network slice, UE IP address, HTCDNN and / or header compression configuration. In response to a message received from the first network function, the CU of the (R)AN may send a message (e.g., a UE context setting request) to the (R)AN's DU. The UE context setting request message may include one or more information elements from the Serving Data Session Response information elements (e.g., a flow synchronization (acceptance) indication, time configuration information). In response to a message received from the CU, the DU may take one or more actions. In an exemplary action, based on a flow synchronization (acceptance) indication, time configuration information, an SDS identifier, at least one QoS control rule (e.g., QoS parameters and / or flow information), and / or at least one packet detection rule (e.g., flow information), the DU of the (R)AN can determine the resources for the SDF / packet flow / QoS flow that needs to be synchronized. For example, based on the flow synchronization (acceptance) indication and / or at least one QoS control rule, the DU can allocate resources for all SDF / packet flow / QoS flows that need to be synchronized. For example, if the DU cannot allocate resources for any of the SDF / packet flow / QoS flow, the DU can reject the CU's request. In the example, the (R)AN can allocate resources for the DRB associated with the SDF / packet flow / QoS flow.

[0413] In an exemplary action, based on the result of determining the resources for the SDF / packet stream / QoS stream that need to be synchronized, the DU can send a message (UE context setting response) to the CU. In the example, the UE context setting response message may include a reason value indicating a successful (resource) request, such as the resource being available for the SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream that needs to be synchronized. In the example, the UE context setting response message may include a reason value indicating a failed (resource) request, such as the resource being unavailable for the SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream. In response to the message received from the DU, the CU can send a message to a first network function including a reason value indicating whether the (resource) request was successful or failed. Based on the reason value, the CU can determine an RRC message and send the RRC message to the UE via the DU. The RRC message may include a reason value indicating whether the (resource) request was successful or failed. In an exemplary action, the CU may send a response message (e.g., a service data session acknowledgment) to the first network function. Service data session acknowledgment messages may include reason values ​​indicating a successful (resource) request, such as the resource being available for an SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream that needs to be synchronized. In the example, a service data session acknowledgment message may include reason values ​​indicating a failed (resource) request, such as the resource being unavailable for an SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream.

[0414] In an exemplary operation, when receiving a data packet from a UE (e.g., uplink), the CU and / or DU can perform data packet synchronization by synchronizing (e.g., simultaneously) the data packets based on a flow synchronization (accept) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the data packet. In an exemplary operation, when receiving an application data packet from a second network function (e.g., downlink), the CU and / or DU can perform data packet synchronization by synchronizing (e.g., simultaneously) the data packets based on a flow synchronization (accept) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the data packet.

[0415] Figure 29An exemplary 5G mobile communication network supporting the synchronization of multiple service data streams is illustrated. In the example, multiple UEs can send multiple service data streams and / or packet streams to an application server / receiver via the 5G communication network in the uplink direction, and the multiple service data streams and / or packet streams may need to be synchronized by the communication network. For example, the 5G communication network may include (R)AN, AMF, SMF, UPF, and / or PCF. In the example, the 5G communication network may include AF. In the example, UE1 can send SDF 1 to the application server / receiver via (R)AN and UPF; UE2 can send SDF 2 to the application server / receiver via (R)AN and UPF; UE3 can send SDF 3 to the application server / receiver via (R)AN and UPF. UE1 may include camera 1, and SDF 1 may include video data 1. UE2 may include camera 2, and SDF 2 may include video data 2. UE3 may include camera 3, and SDF 3 may include video data 3. SDF 1, SDF 2, and SDF 3 can be concurrent streams / data streams that need to be synchronized by the communication network. SDF 1, SDF 2, and SDF 3 can each be part of an application (e.g., a holographic view), and the application server / receiver can reconstruct the application using SDF 1, SDF 2, and SDF 3. In the example, the application server can be the receiver. In the example, the application server can be connected to the receiver. The receiver can be a control / management function of the application. The receiver can be a wireless device. In the example, the application server / receiver can send multiple SDFs to multiple UEs via the communication network in the downlink direction, and the multiple SDFs need to be synchronized by the communication network.

[0416] Figure 30 An exemplary 5G mobile communication network supporting the synchronization of multiple service data streams is illustrated. In the example, multiple data sources (e.g., cameras, sensors) can be connected to a wireless device (UE). Each data source can send different data streams to the UE via a near-field communication network (e.g., Bluetooth, Wi-Fi, etc.). The UE can map the different data streams to different SDFs and can send the different SDFs to an application server / receiver (e.g., a holographic communication (HTC) server) via the 5G communication network (e.g., base station and / or user plane functions) in the uplink direction. The HTC server can perform holographic image reconstruction. In the example, the application server / receiver can send multiple SDFs to the UE via the 5G communication network in the downlink direction, and the multiple SDFs need to be synchronized by the 5G communication network. The UE can map the multiple SDFs to different data streams and send them to different data sources. The procedure for multiple SDFs can be similar to... Figure 29 .

[0417] Figure 31 This is an exemplary invocation flow that may include one or more actions. In the example, the UE may send a NAS message to the AMF, which includes at least one of the following: S-NSSAI, PDU session ID, request type, or N1 SM container (PDU session establishment request). In the example, the NAS message may include at least one of the following information elements: flow synchronization request indication, flow information for multiple SDF / multiple packet streams / QoS streams, the requested Holographic Communication (HTC) network slice for multiple SDF / multiple packet streams / QoS streams; the HTC Data Network Name (DNN) for multiple SDF / multiple packet streams / QoS streams, and / or timestamp information for multiple SDF / multiple packet streams / QoS streams. For example, S-NSSAI may include the HTC network slice (type). The UE may initiate a UE-requested PDU session establishment procedure by transmitting a PDU session establishment request message within the N1 SM container of the NAS message. The PDU session establishment request message may include at least one of the following: PDU session ID, requested PDU session type, or requested SSC mode, etc. In the example, a PDU session establishment request message may include at least one information element: a stream synchronization request indication, stream information, a requested HTC network slice, an HTC DNN, and / or timestamp information. The definition and / or content of at least one information element in the PDU session establishment request message and / or NAS message may be similar to the above reference. Figure 20 At least one information element from the information elements in the first message described. For the sake of brevity, further description will not be repeated here.

[0418] In the example, the UE can transmit NAS messages via RAN nodes (e.g., gNB, eNB, base station). The UE can transmit Radio Resource Control (RRC) messages (e.g., uplink (UL) information transmission messages, RRC setup complete messages, RRC recovery complete messages, RRC reconfiguration complete messages, etc.) that include NAS messages to the RAN nodes. The RAN nodes can transmit N2 messages (e.g., NG messages, initial UE messages, uplink NAS transmission messages, rerouting NAS request messages, handover request messages, initial context setting request messages, PDU session resource setting / modification response messages, PDU session resource modification request messages, etc.) that include NAS messages to the AMF. In response to a NAS message received from the UE, the AMF can select an SMF and send a message (e.g., a PDUssion_CreateSMContext request) to the selected SMF. This message includes at least one of the following: a flow synchronization request indication, flow information, a requested HTC network slice, an HTC DNN, and / or timestamp information, SUPI, PDU session ID, AMF ID, request type, PCF identifier, priority access, N1 SM container (PDU session establishment request), user location information, access type, and PEI. The message sent to the SMF can be used by the AMF to request the establishment of a PDU session. In response to receiving a message from the AMF and / or the UE, the SMF can send a response message (e.g., a Namf_PDUSession_CreateSMContext response) to the AMF indicating whether the request from the AMF is accepted. In the example, the PCF identifier can be an IP address or FQDN that identifies the PCF. In response to a message received from the AMF, the SMF can take one or more actions. In an exemplary action, the SMF may send a response message to the AMF (e.g., a PDUssion_CreateSMContext response) that includes at least one of the following: reason, SM context ID, or N1 SM container (PDU session rejected (reason)).

[0419] In an exemplary operation, if PCC is not deployed, the SMF can determine policies and charging control rules for multiple SDFs / multiple packet flows / QoS flows based on information received from the AMF / UE, user subscription information, and / or local policies. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, an HTC DNN, and / or timestamp information, the SMF can determine at least one policy and charging control rule. In the example, at least one policy and charging control rule can be applied to a PDU session. In the example, at least one policy and charging control rule can be applied to a UE. In the example, at least one policy and charging control rule can be applied to a requested HTC network slice. In the example, at least one policy and charging control rule can be applied to an HTC DNN. In the example, at least one policy and charging control rule can include at least one of the following: a flow synchronization request indication, time configuration information, at least one charging control rule; at least one policy control rule, including at least one QoS control rule and / or at least one gating control rule; at least one usage monitoring control rule; at least one application detection and control rule; at least one traffic redirection control rule; and / or at least one service data flow detection information (e.g., a service data flow template). At least one strategy and fee control rule definition / meaning / content can be similar to the above reference. Figure 20 At least one strategy and fee control rule are described. For the sake of brevity, further descriptions will not be repeated here.

[0420] In the example, based on flow information, the SMF can determine at least one service data flow detection information. For example, at least one service data flow detection information may include filter information. In the example, based on a flow synchronization request indication, the SMF can determine at least one policy control rule and / or at least one QoS control rule. For example, at least one QoS control rule may be applied to / associated with SDF 1, SDF2, and / or SDF 3, and the SMF can determine that SDF 1, SDF2, and / or SDF3 have the same QoS category identifier (e.g., 5QI) and / or the same priority (e.g., ARP). In the example, a flow synchronization request indication in at least one policy and charge control rule can indicate that the service data flow / packet flow / QoS flow associated with at least one policy and charge control rule needs to be synchronized. For example, if the service data flow / packet flow / QoS flow can match at least one service data flow detection information of at least one policy and charge control rule, then the service data flow / packet flow / QoS flow needs to be synchronized. In the example, the SMF can determine the flow synchronization of multiple service data flows / packet flows / QoS flows for multiple policy and charge control rules. For example, SDF1, SDF2, and SDF3 are associated with policy and charge control rule 1 (e.g., policy and charge control rule 1 applies to SDF1, SDF2, and SDF3), and SDF4, SDF5, and SDF6 are associated with policy and charge control rule 2 (e.g., policy and charge control rule 2 applies to SDF4, SDF5, and SDF6). SMF can determine the flow synchronization of SDF1, SDF2, SDF3, SDF4, SDF5, and / or SDF6.

[0421] In the example, SMF can determine timestamp configuration information based on timestamp information. In the example, the timestamp configuration information can indicate the timestamp configuration information for the service data stream / packet stream / QoS stream used for synchronization. The timestamp configuration information can include at least one of the following: timestamp type, timestamp size, timestamp position, and / or the accepted time difference between the SDF / packet stream / QoS stream used for synchronization. For example, the accepted time difference could be 2 milliseconds, SDF 1's timestamp is 1000, and SDF 2's timestamp is 1001. Because the time difference between SDF 1 and SDF 2 is 1 millisecond, which is less than the accepted time difference, SDF 1 and SDF 2 can then be scheduled for synchronization.

[0422] In the example, if PCC is deployed, the SMF can perform a PCF selection procedure by selecting a PCF (e.g., based on the PCF ID). The SMF can perform an SM policy association establishment procedure to establish a PDU session with the selected PCF and obtain the default PCC rules for that PDU session. The SMF can send an SM policy association establishment request message to the selected PCF. The PDU session can be identified by the PDU session ID. The message sent by the SMF to the PCF (e.g., the SM policy association establishment request) can include at least one UE identity (e.g., SUPI, PEI, and / or GPSI) and / or at least one UE IP address (e.g., UE IPv4 address and / or UE IPv6 network prefix). The SM policy association establishment request sent from the SMF to the PCF may include at least one of the following information elements of the PDU session and / or UE: default 5QI and default ARP, PDU session type (e.g., IPv4, IPv6, IPv4v6, Ethernet, unstructured); access type (e.g., 3GPP access), RAT type (e.g., 3GPP-NR-FDD), PLMN identifier, application identifier, assigned application instance identifier, PDU session ID, user location information, and / or SMF information of the PDU session (e.g., SMF identifier, IP address, or FQDN). In the example, the SM policy association establishment request sent from the SMF to the PCF may include at least one information element: flow synchronization request indication, flow information, requested HTC network slice, HTC DNN, and / or timestamp information.

[0423] In response to a message received from the SMF, the PCF can determine policy and charging control rules for multiple SDFs / multiple packet flows / QoS flows based on information received from the SMF, user subscription information, and / or local policies. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, HTC DNN, and / or timestamp information, the PCF can determine at least one policy and charging control rule. In the example, at least one policy and charging control rule can be applied to a PDU session. In the example, at least one policy and charging control rule can be applied to a UE. In the example, at least one policy and charging control rule can be applied to a requested HTC network slice. In the example, at least one policy and charging control rule can be applied to an HTCDNN. In the example, at least one policy and charging control rule can include at least one of the following: a flow synchronization request indication, time configuration information, at least one charging control rule; at least one policy control rule, including at least one QoS control rule and / or at least one gating control rule; at least one usage monitoring control rule; at least one application detection and control rule; at least one traffic redirection control rule; and / or at least one service data flow detection information (e.g., a service data flow template). At least one strategy and fee control rule definition / meaning / content can be similar to the above reference. Figure 20 At least one strategy and fee control rule are described. For the sake of brevity, further descriptions will not be repeated here.

[0424] In the example, based on flow information, the PCF can determine at least one service data flow detection information. For example, at least one service data flow detection information may include filter information. In the example, based on a flow synchronization request indication, the PCF can determine at least one policy control rule and / or at least one QoS control rule. For example, at least one QoS control rule may be applied to / associated with SDF 1, SDF2, and / or SDF 3, and the PCF can determine that SDF 1, SDF2, and / or SDF3 have the same QoS category identifier (e.g., 5QI) and / or the same priority (e.g., ARP). In the example, a flow synchronization request indication in at least one policy and charge control rule can indicate that the service data flow / packet flow / QoS flow associated with at least one policy and charge control rule needs to be synchronized. For example, if the service data flow / packet flow / QoS flow can match at least one service data flow detection information of at least one policy and charge control rule, then the service data flow / packet flow / QoS flow needs to be synchronized. In the example, the PCF can determine the flow synchronization of multiple service data flows / packet flows / QoS flows for multiple policy and charge control rules. For example, SDF1, SDF2, and SDF3 are associated with policy and charging control rule 1 (e.g., policy and charging control rule 1 applies to SDF1, SDF2, and SDF3), and SDF4, SDF5, and SDF6 are associated with policy and charging control rule 2 (e.g., policy and charging control rule 2 applies to SDF4, SDF5, and SDF6). PCF can determine the stream synchronization of SDF1, SDF2, SDF3, SDF4, SDF5, and / or SDF6.

[0425] In the example, PCF can determine timestamp configuration information based on timestamp information. In the example, the timestamp configuration information can indicate the timestamp configuration information for the service data stream / packet stream / QoS stream used for synchronization. The timestamp configuration information can include at least one of the following: timestamp type, timestamp size, timestamp position, and / or the accepted time difference between the SDF / packet stream / QoS stream used for synchronization. For example, the accepted time difference could be 2 milliseconds, SDF 1's timestamp is 1000, and SDF 2's timestamp is 1001. Because the time difference between SDF 1 and SDF 2 is 1 millisecond, which is less than the accepted time difference, SDF 1 and SDF 2 can then be synchronized and scheduled.

[0426] In an exemplary action, the PCF may send a response message (e.g., an SM policy association establishment response) to the SMF, including at least one policy and charge control rule and / or flow synchronization request indication. The SM policy association establishment response message may include at least one information element: at least one UE identity (e.g., SUPI, PEI, and / or GPSI), at least one UE IP address (e.g., UE IPv4 address and / or UE IPv6 network prefix), default 5QI and default ARP, PDU session type (e.g., IPv4, IPv6, IPv4v6, Ethernet, unstructured), access type (e.g., 3GPP access), RAT type (e.g., 3GPP-NR-FDD), PLMN identifier, application identifier, and / or PDU session ID. The flow synchronization request indication in the SM policy association establishment response message may indicate a request for synchronization of SDF / packet flow / QoS flows for multiple policies and charge control rules in the SM policy association establishment response message.

[0427] In response to receiving a message from the PCF, the SMF may take one or more actions. In an exemplary action, the SMF may select a CHF based on a Stream Synchronization Request Indication, Stream Information, the requested HTC network slice, the HTC DNN, and / or at least one policy and charging control rule. For example, the SMF may determine the CHF based on the requested HTC network slice, such that the selected CHF supports charging for the HTC network slice. In an exemplary action, the SMF may send a message (e.g., a Charging Data Request) to the CHF, the message including at least one of the following: a Stream Synchronization Request Indication, Stream Information, the requested HTC network slice, the HTC DNN, a Serving Data Session Identifier; UE identity, Serving Data Session Type, PLMN identifier, and / or user location information.

[0428] In response to a chargeable data request message received from the SMF, the CHF can determine the quota for the service data session and / or SDF / packet flow / QoS flow based on information received from the SMF. In an example, the quota may include at least one of the following: authorized unit; time quota threshold; or quantity quota threshold. In an example, based on a flow synchronization request indication, flow information, the requested HTC network slice, and / or HTC DNN, the CHF can determine the higher authorized unit for the service data session and / or SDF / packet flow / QoS flow. The CHF may send a response message (e.g., a chargeable data response) to the SMF including the quota, service data session identifier, UE identity, and / or flow information for the SDF / packet flow / QoS flow.

[0429] In response to a message received from the CHF and / or PCF, the SMF may take one or more actions. In exemplary actions, the SMF may determine at least one user plane rule based on at least one policy and charge control rule and / or quota. For example, based on a flow synchronization request indication, flow information, a requested HTC network slice, an HTC DNN, at least one policy and charge control rule and / or quota, the SMF may determine at least one user plane rule. In the example, at least one user plane rule may be applied to a service data flow / packet flow / QoS flow. In the example, at least one user plane rule may be applied to a service data session. In the example, at least one user plane rule may be applied to a UE. In the example, at least one user plane rule may be applied to a requested HTC network slice. In the example, at least one user plane rule may be applied to an HTC DNN. In the example, at least one user plane rule may include at least one of the following: a flow synchronization request indication, time configuration information, at least one packet detection rule, at least one forwarding action rule, at least one QoS enforcement rule, and / or at least one usage reporting rule. The definition / meaning / content of at least one user plane rule may be similar to the above reference. Figure 20 At least one user plane rule is described. For the sake of brevity, further descriptions will not be repeated here.

[0430] In an exemplary operation, the SMF can select a UPF based on a stream synchronization request indication, stream information, a requested HTC network slice, an HTCDNN, at least one policy and charging control rule, and / or at least one user plane rule. For example, the SMF can determine the UPF based on a stream synchronization request indication, where the selected UPF supports stream synchronization functionality. Alternatively, the SMF can determine the UPF based on a requested HTC network slice, where the selected UPF supports HTC network slices.

[0431] In an exemplary action, the SMF may send a message (e.g., an N4 session establishment / modification request) to the UPF. The N4 session establishment / modification request message may indicate a request for synchronization of service data streams / packet streams / QoS streams. For example, the N4 session establishment / modification request message may include at least one information element: a stream synchronization (request) indication, at least one user plane rule, and / or time configuration information. The stream synchronization (request) indication in the N4 session establishment / modification request message may indicate that the service data stream / packet stream / QoS stream associated with the N4 session establishment / modification request message needs to be synchronized. For example, the N4 session establishment / modification request message may include user plane rule 1 and user plane rule 2, where user plane rule 1 may include packet detection rule 1, and user plane rule 2 may include packet detection rule 2. The stream synchronization (request) indication in the N4 session establishment / modification request message may indicate that the SDF / packet stream / QoS stream matching packet detection rule 1 needs to be synchronized with the SDF / packet stream / QoS stream matching packet detection rule 2. For example, an N4 session establishment / modification request message may include user plane rule 1 and user plane rule 2, with SDF1, SDF2, and SDF3 associated with user plane rule 1 (e.g., user plane rule 1 applies to SDF1, SDF2, and SDF3), and SDF4, SDF5, and SDF6 associated with user plane rule 2 (e.g., user plane rule 2 applies to SDF4, SDF5, and SDF6). The stream synchronization (request) indication in the N4 session establishment / modification request message may indicate that SDF1, SDF2, SDF3, SDF4, SDF5, and / or SDF6 need to be synchronized. In response to a message received from the SMF, the UPF may install at least one user plane rule and send a response message (e.g., an N4 session establishment / modification response) to the SMF.

[0432] In an exemplary action, the SMF can send a message to the AMF message (e.g., Namf_Communication_N1N2MessageTransfer). In the example, the Namf_Communication_N1N2MessageTransfer message can indicate the synchronization of the received service data stream / packet stream / QoS stream. In the example, the Namf_Communication_N1N2MessageTransfer message can include at least one of the following: PDU session ID, access type, N2 SM information (PDU session ID, QFI, QoS profile, CN tunnel information, S-NSSAI, session-AMBR, PDU session type, etc.), N1 The SM container (PDU session establishment accepts QoS rules, selected SSC mode, S-NSSAI, allocated IPv4 address, interface identifier, session-AMBR, selected PDU session type, etc.). In the example, the Namf_Communication_N1N2MessageTransfer message can indicate acceptance of service data stream / packet stream / QoS stream synchronization. For example, the Namf_Communication_N1N2MessageTransfer message can include at least one information element: stream synchronization (acceptance) indication, time configuration information, stream information, at least one QoS control rule and / or at least one packet detection rule. In the example, the stream synchronization (acceptance) indication can indicate that the network has accepted the request for service data stream / packet stream / QoS stream synchronization. In the example, the stream synchronization (acceptance) indication can indicate that the network requests the synchronization of service data stream / packet stream / QoS stream. In the example, N2 The SM information can carry information that the AMF can forward to the (R)AN (e.g., CN tunnel information corresponding to the core network address of the N3 tunnel corresponding to the PDU session, providing one or more QoS profiles and corresponding QFIs to the (R)AN, the PDU session ID being used by signaling to the UE to indicate the association between the UE's AN resources and the PDU session, etc.). In the example, the N1 SM container can contain a PDU session establishment acceptance that the AMF can provide to the UE. In the example, multiple QoS rules and QoS profiles can be included in the PDU session establishment acceptance within the N1 SM container and in the N2 SM information. In the example, Namf_Communication_N1N2MessageTransfer can also include the PDU session ID and information that allows the AMF to know which access is being used towards the UE. In the example, the QoS profile can include flow information.

[0433] In the example, the AMF can send a message (e.g., an N2 PDU session request) to the (R)AN. In the example, the N2 PDU session request message can indicate the acceptance of synchronization of the service data stream / packet stream / QoS stream. In the example, the N2 PDU session request message can include at least one of the following: N2 SM information, NAS message (PDU session ID, N1 SM container (PDU session establishment acceptance, etc.)). In the example, the AMF can send a NAS message to the (R)AN, which can include the PDU session ID and a PDU session establishment acceptance for the UE, as well as the N2 SM information received from the SMF within the N2 PDU session request. In the example, the N2 PDU session request message can include at least one of the following: stream synchronization (acceptance) indication, time configuration information, stream information, at least one QoS control rule and / or at least one packet detection rule.

[0434] In response to a message received from the AMF, (R)AN may take one or more actions. In an example action, (R)AN may take actions such as... Figure 33 The actions described herein. In an exemplary action, based on a flow synchronization (accept) indication, time configuration information, PDU session ID, QoS profile, flow information, at least one QoS control rule (e.g., QoS parameters and / or flow information), and / or at least one packet detection rule (e.g., flow information), (R)AN can determine the resources for the SDF / packet flow / QoS flow that needs to be synchronized. For example, based on a flow synchronization (accept) indication, QoS profile, and / or at least one QoS control rule, (R)AN can allocate resources for all SDF / packet flow / QoS flows that need to be synchronized. For example, if (R)AN cannot allocate resources for any of the SDF / packet flow / QoS flow, (R)AN can reject the AMF request. In the example, (R)AN can allocate resources for the DRB associated with the SDF / packet flow / QoS flow.

[0435] In the example, (R)AN can send specific signaling to the UE, which includes information received from the SMF via the AMF. In the example, (R)AN can forward NAS messages (PDU session ID, N1 SM container (PDU session establishment acceptance)) to the UE. In the example, the specific signaling and / or NAS messages sent to the UE can indicate the synchronization of accepted service data streams / packet streams / QoS streams. If the necessary RAN resources are established and (R)AN tunnel information is successfully allocated, (R)AN can provide NAS messages to the UE. In the example, the AN-specific signaling sent by (R)AN to the UE can include stream synchronization (acceptance) indications, time configuration information, and / or stream information.

[0436] In response to a message received from the (R)AN, the UE can send data packets to the (R)AN. For example, the data packet can be at least one of multiple SDFs. For example, the data packet can be at least one of multiple packet streams. For example, the data packet can be a QoS stream. In the example, the data packet sent by the UE can include a timestamp. For example, the timestamp can indicate the time the UE sent the data packet. In the example, the timestamp can be an absolute time (e.g., the current time). In the example, the timestamp can be a relative time; for example, the timestamp can include a second number since January 1, 1900. For example, the timestamp can be a Network Time Protocol (NTP) timestamp. In the example, the timestamp can be in the IP header (e.g., IP Option 4). In the example, the timestamp can be in the Transmission Control Protocol (TCP) header. In the example, the timestamp can be at the end of the payload of an Ethernet packet. In the example, the timestamp can be at the end of the payload of a TCP / IP packet. In the example, the timestamp can be at the end of the payload of an IP packet.

[0437] In response to a data packet received from the UE, and / or in response to a message received from the AMF, the (R)AN can perform data packet synchronization by synchronizing (e.g., simultaneously) scheduling data packets based on a flow synchronization (acceptance) indication, time configuration information, flow information, QoS profile, at least one QoS control rule, at least one packet detection rule, and / or timestamps in the data packets. For example, the (R)AN can receive SDF 1, SDF 2, and / or SDF 3 from the UE. SDF 1 may include timestamp 1, SDF 2 may include timestamp 1 + Δt, and SDF 3 may include timestamp 1 – Δt, for example, Δt is 2 milliseconds. The (R)AN can detect that SDF 1, SDF 2, and / or SDF 3 match at least one packet detection rule. Based on the flow synchronization (acceptance) indication and / or time configuration information (e.g., the acceptance time difference between SDFs is 1 millisecond), the (R)AN can synchronize (e.g., simultaneously) schedule SDF 1, SDF 2, and / or SDF 3. Based on CN tunnel information, (R)AN can synchronously send / forward SDF, SDF 2 and / or SDF 3 to UPF. Figure 27A This is an exemplary diagram depicting a base station performing synchronization of multiple service data streams according to an embodiment of this disclosure. In the example, in response to a data packet received from (R)AN, and / or in response to a message received from SMF, the UPF can execute at least one user plane rule. The procedure by which the UPF executes at least one user plane rule can be similar to that described above. Figure 20 The procedure described here executes at least one user plane rule by a second network function. For the sake of brevity, further description will not be repeated here.

[0438] In the example, in response to packets received from (R)AN and / or messages received from SMF, the UPF can perform packet synchronization by synchronously (e.g., simultaneously) scheduling packets based on at least one user plane rule and / or timestamps in the packets. For example, the UPF can receive QoS stream 1 and / or QoS stream 2 from (R)AN. QoS stream 1 may include SDF1, SDF2, and / or SDF3, and QoS stream 2 may include SDF4, SDF5, and / or SDF6. SDF1 may include timestamp 1, SDF2 may include timestamp 1 + Δt, and SDF3 may include timestamp 1 – Δt. SDF4 may include timestamp 1, SDF5 may include timestamp 1 + Δt, and SDF6 may include timestamp 1 – Δt. For example, Δt is 2 milliseconds. UPF can detect packet detection rule 1 where SDF1, SDF2, and / or SDF3 match at least one user plane rule, and UPF can detect packet detection rule 2 where SDF4, SDF5, and / or SDF6 match at least one user plane rule. Based on stream synchronization (request) indications and / or time configuration information (e.g., a 1-millisecond time difference between SDFs), UPF can synchronously (e.g., simultaneously) schedule SDF1, SDF2, SDF3, SDF4, SDF5, and / or SDF6. UPF can synchronously send / forward SDF1, SDF2, SDF3, SDF4, SDF5, and / or SDF6 to the receiver / server / AF. Figure 28A This is an exemplary diagram depicting a user plane function that performs synchronization of multiple service data streams according to an embodiment of this disclosure. In response to receiving a data packet (e.g., SDF / packet stream / QoS stream) from the UPF, the receiver / server / AF can take one or more actions. In an exemplary action, the receiver / server / AF can reconstruct an application (e.g., a holographic view, holographic video) using the received data packet (e.g., SDF / packet stream / QoS stream).

[0439] In an exemplary operation, the receiver / server / AF may send application packets (e.g., SDF / packet stream / QoS stream) to the UE via UPF and / or (R)AN. For example, the receiver / server / AF may send video / audio packets to the UE. For example, the receiver / server / AF may send control signaling to the UE that can change the angle of the camera / sensor. For example, the receiver / server / AF may send acknowledgment packets (e.g., TCP ACK) to the UE. In the example, the application packets sent by the receiver / server / AF may include time information. In the example, the packets sent by the receiver / server / AF may include a timestamp. For example, the timestamp may indicate the time when the receiver / server / AF sent the packets. In the example, the timestamp may be an absolute time (e.g., current time). In the example, the timestamp may be a relative time; for example, the timestamp may include a second number since January 1, 1900. For example, the timestamp may be a Network Time Protocol (NTP) timestamp. In the example, the timestamp may be in the IP header (e.g., IP Option 4). In the example, the timestamp may be in the Transmission Control Protocol (TCP) header. In the examples, the timestamp can be at the end of the Ethernet packet payload. In the examples, the timestamp can be at the end of the TCP / IP packet payload. In the examples, the timestamp can be at the end of the IP packet payload. In response to receiving application packets from the receiver / server / AF, the UPF can perform application packet synchronization by synchronously (e.g., simultaneously) scheduling application packets based on at least one user plane rule and / or the timestamp in the application packets. The UPF can synchronously send / forward application packets (SDF / packet stream / QoS stream) to the (R)AN. Figure 28B This is an exemplary diagram depicting a user plane function that performs synchronization of multiple service data streams according to an embodiment of this disclosure. In response to receiving an application data packet from the UPF, the (R)AN can perform data packet synchronization by synchronously (e.g., simultaneously) scheduling the data packets based on a stream synchronization (acceptance) indication, time configuration information, stream information, QoS profile, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the application data packet. The (R)AN can synchronously send / forward application data packets (SDF / packet stream / QoS stream) to the UE. Figure 27BThis is an exemplary diagram depicting a base station performing synchronization of multiple service data streams according to aspects of embodiments of this disclosure. In response to receiving an application data packet from the (R)AN, the UE can take one or more actions. For example, when receiving video / audio data packets from a receiver / server / AF, the UE can play video and / or audio. For example, the UE can take actions based on control signaling from the receiver / server / AF, such as changing the angle of a camera / sensor. For example, the UE can send multiple SDFs to multiple cameras / sensors to control some actions of the cameras / sensors. For example, the UE can send multiple SDFs to multiple cameras / sensors to change the angle of the cameras / sensors. In the example, the UE can send multiple SDFs to the cameras / sensors via WiFi, Bluetooth, etc.

[0440] Figure 32 This can be an exemplary call flow that may include one or more actions. In the example, such as... Figure 29 As shown, a communication system can have up to three UEs. (Back) Figure 32 UE 1 may have established PDU session 1 with the 5G communication network, and PDU session 1 may include bidirectional (e.g., uplink and / or downlink) SDF 1. UE 2 may have established PDU session 2 with the 5G communication network, and PDU session 2 may include bidirectional (e.g., uplink and / or downlink) SDF 2. UE 3 may have established PDU session 3 with the 5G communication network, and PDU session 3 may include bidirectional (e.g., uplink and / or downlink) SDF 3. The receiver / server / AF may have application layer signaling (e.g., SIP / SDP) with each of the three UEs respectively. The receiver / server / AF may send messages (e.g., application information provision) to the PCF. The application information provision message may indicate the synchronization of multiple SDFs / multiple packet flows / QoS flows. For example, an application information provision message may include at least one information element: a stream synchronization request indication, stream information for multiple SDFs (e.g., SDF 1, SDF 2, and / or SDF 3) / multiple packet streams / QoS streams, a Holographic Communications (HTC) network slice requesting multiple SDFs / multiple packet streams / QoS streams, HTC Data Network Names (DNNs) for multiple SDFs / multiple packet streams / QoS streams, timestamp information for multiple SDFs / multiple packet streams / QoS streams, an identifier for PDU session 1, an identifier for PDU session 2, and / or an identifier for PDU session 3. The definition / meaning of at least one information element may be similar to that referenced above. Figure 20 The information elements described. For the sake of brevity, further descriptions will not be repeated here.

[0441] In response to a message received from a receiver / server / AF, the PCF may take one or more actions. In exemplary actions, based on information provided by the application information message, user subscription information, and / or local policies, the PCF may determine at least one policy and charging control rule for multiple SDFs / multiple packet flows / QoS flows. For example, based on a flow synchronization request indication, flow information, the requested HTC network slice, HTC DNN, and / or timestamp information, the PCF may determine at least one policy and charging control rule. In the example, at least one policy and charging control rule may be a new policy and charging control rule. In the example, at least one policy and charging control rule may be an updated policy and charging control rule; for example, the first network function may update existing policy and charging control rules based on information provided by the application information message and / or user subscription information and / or local policies. The procedure and / or content for determining at least one policy and charging control rule may be similar to the above reference. Figure 20 The description includes at least one policy and the procedure and / or content for determining the fee control rules. For the sake of brevity, further descriptions will not be repeated here.

[0442] In an exemplary action, the PCF may send a message to the SMF (e.g., SM policy association modification). The SM policy association modification message may include at least one policy and charging control rule and / or flow synchronization request indication. In the example, the SM policy association modification message may include at least one information element: an identifier for PDU session 1, an identifier for PDU session 2 and / or an identifier for PDU session 3, at least one UE identity (e.g., SUPI, PEI, and / or GPSI), at least one UE IP address for each PDU session in the PDU session (e.g., UE IPv4 address and / or UE IPv6 network prefix), a default 5QI and default ARP for each PDU session in the PDU session, a PDU session type for each PDU session in the PDU session (e.g., IPv4, IPv6, IPv4v6, Ethernet, unstructured), an access type for each PDU session in the PDU session (e.g., 3GPP access), a RAT type for each PDU session in the PDU session (e.g., 3GPP-NR-FDD), a PLMN identifier, and / or an application identifier. The Stream Synchronization Request Instruction in the SM Policy Association Establishment Response Message can instruct the synchronization of SDF / packet / QoS streams for multiple policies and charge control rules in the SM Policy Association Modification Message.

[0443] In response to a message received from the PCF, the SMF may take one or more actions. In an exemplary action, the SMF may determine at least one user plane rule based on at least one policy and charging control rule. In the example, the at least one user plane rule may be a new user plane rule. In the example, the at least one user plane rule may be an updated user plane rule; for example, the first network function may update an existing user plane rule based on at least one policy and charging control rule. The procedure and / or content for determining the at least one user plane rule may be similar to the above reference. Figure 20 The description includes the procedure and / or content for determining at least one user plane rule. For the sake of brevity, further descriptions will not be repeated here.

[0444] In an exemplary action, the SMF may send a message (e.g., an N4 session establishment / modification request) to the UPF. The N4 session establishment / modification request message may indicate a request for synchronization of service data streams (e.g., SDF 1, SDF 2, and / or SDF 3) / packet streams / QoS streams. For example, the N4 session establishment / modification request message may include at least one information element: a stream synchronization (request) indication, at least one user plane rule, time configuration information, an identifier for PDU session 1, an identifier for PDU session 2, and / or an identifier for PDU session 3. In response to the message received from the SMF, the UPF may execute at least one user plane rule. The procedure for executing at least one user plane rule may be similar to the above reference. Figure 20 The description specifies the execution of at least one user plane rule. For the sake of brevity, further details will not be repeated here.

[0445] In an exemplary action, the SMF may send a message (e.g., Namf_Communication_N1N2MessageTransfer) to the AMF. The Namf_Communication_N1N2MessageTransfer message may instruct the synchronization of service data flows (e.g., SDF 1, SDF 2, and / or SDF 3) / packet flows / QoS flows. The Namf_Communication_N1N2MessageTransfer message may include at least one of the following: N2 SM information and / or an N1 SM container. The N2 SM information may include at least one of the following: PDU session ID, QFI, QoS profile, alternative QoS profile, session-AMBR, CN tunnel information, QoS monitoring indication, QoS monitoring report frequency, and / or TSCAI. The N1 SM container may include a PDU session modification command, wherein the PDU session modification command may include at least one of the following: PDU session ID, QoS rule, QoS flow-level QoS parameters (if required by the QoS flow associated with the QoS rule), QoS rule operation and QoS flow-level QoS parameter operation, and / or session-AMBR. In the example, the Namf_Communication_N1N2MessageTransfer message and / or the N2 SM information and / or the N1 SM container may include at least one of the following: a flow synchronization (request) indication, at least one user plane rule, time configuration information, an identifier for PDU session 1, an identifier for PDU session 2, an identifier for PDU session 3, flow information, at least one QoS control rule, and / or at least one packet detection rule. In the example, the flow synchronization (request) indication may indicate that the network requests synchronization of the service data flow / packet flow / QoS flow. In the example, the N2 SM information may carry information that the AMF can forward to the (R)AN. In the example, the N1 SM container may contain information that the AMF can provide to the UE. In the example, multiple QoS rules and QoS profiles may be included in the N1 SM container and the N2 SM information. In the example, the QoS profile may include flow information.

[0446] In the example, the AMF can send a message to the (R)AN (e.g., an N2 PDU session request). In the example, the N2 PDU session request message can indicate a request for synchronization of service data streams / packet streams / QoS streams. In the example, the N2 PDU session request message can include at least one of the following: N2 SM information, NAS message (N1 SM container). In the example, the N2 PDU session request message can include at least one of the following: an identifier for PDU session 1, an identifier for PDU session 2, an identifier for PDU session 3, a stream synchronization (request) indication, time configuration information, stream information, at least one QoS control rule, and / or at least one packet detection rule.

[0447] In response to a message received from the AMF, (R)AN may take one or more actions. In an example action, (R)AN may take actions such as... Figure 33 The actions described herein. In an exemplary action, (R)AN may send AN-specific signaling to UE 1, UE 2, and UE 3, respectively. AN-specific signaling may include one or more information elements received from the AMF. For example, AN-specific signaling sent to the UE may instruct the synchronization of service data streams / packet streams / QoS streams. For example, AN-specific signaling sent to the UE may include at least one of the following: stream synchronization indication, PDU session ID (e.g., identifier of PDU session 1, identifier of PDU session 2, or identifier of PDU session 3), stream synchronization (request) indication, time configuration information, at least one QoS control rule, a packet detection rule, CN tunnel information, accepted network slice (e.g., HTC network slice), UE IP address, HTCDNN, and / or header compression configuration.

[0448] In response to a message received from the (R)AN, UE 1, UE 2, and / or UE 3 may send (uplink) data packets to the receiver / server / AF. The (uplink) data packets may be processed / forwarded via the (R)AN and / or the UPF. In the example, the receiver / server / AF may send (downlink) application data packets to UE 1, UE 2, and / or UE 3. The (downlink) application data packets may be processed / forwarded via the UPF and / or the (R)AN. The procedures for the UE, (R)AN, UPF, and / or receiver / server / AF may be similar to those described in the reference above. Figure 31 The program is described. For the sake of brevity, further descriptions will not be repeated here.

[0449] Figure 33 This is an exemplary call flow that may include one or more actions. In the example, (for example, see...) Figure 31 and / or Figure 32In response to a message received from the AMF, the (R)AN's CU can send a message (e.g., an N2 PDU session request) to the (R)AN (e.g., the (R)AN's CU). The N2 PDU session request message may include at least one information element: a flow synchronization (acceptance) indication, time configuration information, a PDU session ID, at least one QoS control rule (e.g., QoS parameters and / or flow information), at least one packet detection rule (e.g., flow information), CN tunnel information, accepted network slices, UE IP address, HTC DNN and / or header compression configuration. In response to a message received from the AMF, the (R)AN's CU can send a message (e.g., a UE context setting request) to the (R)AN's DU. The UE context setting request message may include one or more information elements from the N2 PDU session request message (e.g., a flow synchronization (acceptance) indication, time configuration information). In response to a message received from the CU, the DU may take one or more actions. In an exemplary action, based on a flow synchronization (accept) indication, time configuration information, PDU session ID, at least one QoS control rule (e.g., QoS parameters and / or flow information), and / or at least one packet detection rule (e.g., flow information), the DU of the (R)AN can determine the resources for the SDF / packet flow / QoS flow that needs to be synchronized. For example, based on the flow synchronization (accept) indication and / or at least one QoS control rule, the DU can allocate resources for all SDF / packet flow / QoS flows that need to be synchronized. For example, if the DU cannot allocate resources for any of the SDF / packet flow / QoS flow, the DU can reject the CU's request. In the example, the (R)AN can allocate resources for the DRB associated with the SDF / packet flow / QoS flow.

[0450] In an exemplary action, based on the result of determining the resources for the SDF / packet stream / QoS stream that need to be synchronized, the DU can send a message (UE context setting response) to the CU. In the example, the UE context setting response message may include a reason value indicating a successful (resource) request, such as the resource being available for the SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream that needs to be synchronized. In the example, the UE context setting response message may include a reason value indicating a failed (resource) request, such as the resource being unavailable for the SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream. In response to the message received from the DU, the CU can send a message to the AMF including a reason value indicating whether the (resource) request was successful or failed. Based on the reason value, the CU can determine an RRC message and send the RRC message to the UE via the DU. The RRC message may include a reason value indicating whether the (resource) request was successful or failed. In an exemplary action, the CU may send a response message to the AMF (e.g., an N2 PDU session acknowledgment). The N2 PDU session acknowledgment message may include a reason value indicating that the (resource) request was successful, such as the resource being available for an SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream that needs to be synchronized. In the example, the N2 PDU session acknowledgment message may also include a reason value indicating that the (resource) request failed, such as the resource being unavailable for an SDF / packet stream / QoS stream and / or the DRB associated with the SDF / packet stream / QoS stream.

[0451] In an exemplary operation, when receiving data packets from the UE (e.g., uplink), the CU and / or DU can perform data packet synchronization by synchronizing (e.g., simultaneously) the data packets based on a flow synchronization (accept) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the data packets. In an exemplary operation, when receiving application data packets from the UPF (e.g., downlink), the CU and / or DU can perform data packet synchronization by synchronizing (e.g., simultaneously) the data packets based on a flow synchronization (accept) indication, time configuration information, at least one QoS control rule, at least one packet detection rule, and / or a timestamp in the data packets.

[0452] In the example, the first network function (FNF) can receive a first message from the wireless device requesting a Service Data Session (SDS) from the wireless device. The first message may include a Stream Synchronization Request Indication (FSRI) requesting synchronization of multiple Service Data Streams (SDFs). In the example, based on the FSRI, the FNF can determine the policies and charging control rules for the multiple SDFs. In the example, based on the policies and charging control rules, the FNF can determine the user plane rules for the multiple SDFs. In the example, the FNF can send the user plane rules to the second network function (SNF).

[0453] In an exemplary embodiment, the first network function may be a control plane function. In an exemplary embodiment, the control plane function may be a Session Management Function (SMF). In an exemplary embodiment, the second network function may be a User Plane Function (UPF). In an exemplary embodiment, the first message may further include at least one of the following: flow information of multiple SDFs; a requested Holographic Communications (HTC) network slice of multiple SDFs; HTC Data Network Names (DNNs) of multiple SDFs; and / or timestamp information. In an exemplary embodiment, the flow information of multiple SDFs may further include at least one of the following: flow identifiers of multiple SDFs; and / or flow filter information of multiple SDFs. In an exemplary embodiment, the flow information may further include at least one of the following: an IP packet filter set and / or an Ethernet packet filter set. In an exemplary embodiment, the requested HTC network slice may indicate a network slice having an HTC service type. In an exemplary embodiment, the requested HTC network slice may indicate that multiple SDFs of the requested HTC network slice are requested to be synchronized. In an exemplary embodiment, the HTC DNN may indicate that multiple SDFs of the DNN are requested to be synchronized. In exemplary embodiments, timestamp information may further include at least one of the following: timestamp type, timestamp size, and / or timestamp location. In exemplary embodiments, timestamp type may indicate at least one of the following: absolute time, relative time, and / or NTP timestamp. In exemplary embodiments, policy and charge control rules may further include at least one of the following: flow synchronization request indication and / or time configuration information. In exemplary embodiments, time configuration information may further include at least one of the following: timestamp type, timestamp size, timestamp location, or the time difference between accepted SDF / packet flow / QoS flow used for synchronization. In exemplary embodiments, policy and charge control rules may further include at least one of the following: charge control rules; policy control rules; usage monitoring control rules; application detection and control rules; traffic redirection control rules; and / or service data flow detection information. In exemplary embodiments, policy control rules may include at least one of the following: QoS control rules; and / or gating control rules. In exemplary embodiments, user plane rules may further include at least one of the following: flow synchronization request indication, time configuration information, packet detection rules, forwarding action rules, QoS enforcement rules, and / or usage reporting rules. In an exemplary implementation, the SNF can receive multiple SDFs, wherein the multiple SDFs may include timestamp information. In an exemplary implementation, the SNF can perform stream synchronization of the multiple SDFs based on user plane rules. In an exemplary implementation, the SNF can perform stream synchronization of the multiple SDFs based on the timestamp information of the multiple SDFs.In an exemplary embodiment, the SNF can allocate resources to multiple SDFs based on user plane rules. In an exemplary embodiment, the FNF can send at least one information element to the base station: a flow synchronization request indication, flow information for the multiple SDFs, a requested HTC network slice, HTC DNN, and / or time configuration information. In an exemplary embodiment, the base station can receive multiple SDFs, wherein the multiple SDFs include timestamp information. In an exemplary embodiment, the base station can perform flow synchronization of the multiple SDFs based on at least one information element. In an exemplary embodiment, the base station can perform flow synchronization of the multiple SDFs based on the timestamp information of the multiple SDFs. In an exemplary embodiment, the base station can allocate resources to the multiple SDFs. In an exemplary embodiment, the FNF can receive from the base station a reason value indicating that the base station cannot allocate resources to the multiple SDFs. In an exemplary embodiment, the FNF can send at least one information element to the base station via the Access and Mobility Management Function (AMF). In an exemplary embodiment, the FNF can send a charge request message to the Charging Function (CHF), wherein the charge request message can include a flow synchronization request indication. In an exemplary embodiment, the CHF can determine a quota based on the charge request message. In an exemplary embodiment, the FNF can receive a charge response including the quota.

[0454] In the example, a second network function (SNF) can receive a first message from a first network function, the first message including user plane rules for multiple Service Data Streams (SDFs). The user plane rules may include a Stream Synchronization Request Indication (FSRI) requesting synchronization of the multiple SDFs. In the example, the SNF can receive multiple SDFs. In the example, based on the user plane rules, the SNF can perform synchronization of the multiple SDFs. In an exemplary embodiment, the SNF can receive multiple SDFs from one or more wireless devices. In an exemplary embodiment, each of the multiple SDFs may include time information indicating when the one or more wireless devices send each of the multiple SDFs. In an exemplary embodiment, the SNF can receive multiple SDFs from an application server. In an exemplary embodiment, each of the multiple SDFs includes time information indicating when the application server sends each of the multiple SDFs. In an exemplary embodiment, execution may include scheduling packets of multiple SDFs simultaneously. In an exemplary embodiment, scheduling packets may be based on the time information of each of the multiple SDFs. In an exemplary embodiment, the time information may be a timestamp. In an exemplary embodiment, the time information may be a relative time. In an exemplary embodiment, the time information may be an absolute time.

[0455] In the example, the base station can receive a first message from a first network function (FNF). The first message may include a Stream Synchronization Request Indication (FSRI) requesting synchronization of multiple Serving Data Streams (SDFs). In the example, the base station can receive packets of multiple SDFs. In the example, based on the FSRI, the base station can perform synchronization of the multiple SDFs. In the example, the wireless device can send a first message to a first network function (FNF). The first message may include a Stream Synchronization Request Indication (FSRI) requesting synchronization of multiple Serving Data Streams (SDFs). In the example, the wireless device can receive a response message from the FNF. The response message may indicate acceptance of synchronization of the multiple SDFs. In the example, the wireless device can send packets of at least one of the multiple SDFs to the base station. In the example, the wireless device can receive application data packets of at least one of the multiple SDFs from the base station. In an exemplary embodiment, each of the multiple SDFs may include timing information indicating when the wireless device sends each of the multiple SDFs.

[0456] In the example, the first network function (FNF) can receive a first message from the application function. The first message may include a Flow Synchronization Request Indication (FSRI) that requests synchronization of multiple Service Data Streams (SDFs). In the example, based on the FSRI, the FNF can determine the policies and charging control rules for the multiple SDFs. In the example, based on the policies and charging control rules, the FNF can determine the user plane rules for the multiple SDFs. In the example, the FNF can send the user plane rules to the second network function (SNF).

[0457] In an exemplary embodiment, the FNF may be a policy control function. In an exemplary embodiment, the first message may further include at least one of the following: flow information for multiple SDFs; a requested Holographic Communication (HTC) network slice for the multiple SDFs; and / or the HTC Data Network Name (DNN) for the multiple SDFs. In an exemplary embodiment, the flow information for the multiple SDFs may further include at least one of the following: flow identifiers for the multiple SDFs; and / or flow filter information for the multiple SDFs. In an example, the centralized unit (CU) of the base station may receive the first message from the first network function (FNF). The first message may include a Flow Synchronization Request Indication (FSRI) indicating a request for synchronization of multiple Serving Data Streams (SDFs). In an example, the CU may send the FSRI to the distributed unit of the base station. In an example, the CU may receive multiple SDFs. In an example, the base station may perform flow synchronization of the multiple SDFs.

[0458] According to various implementation schemes, one or more devices, such as wireless devices, off-network wireless devices, base stations, core network devices, etc., may be employed in the system. One or more devices may be configured to perform specific operations or actions by installing software, firmware, hardware, or combinations thereof on the one or more devices, which, in operation, cause or induce the one or more devices to perform actions. One or more computer programs may be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions. Embodiments of exemplary actions are illustrated in the accompanying drawings and description. Features from various implementation schemes can be combined to create other implementation schemes.

[0459] In this specification, “a” (“a” and “an”) and similar phrases will be interpreted as “at least one” and “one or more”. In this specification, the term “may” is interpreted as “may, for example.” In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a variety of suitable possibilities that may or may not be used in one or more of various examples. If A and B are sets, and every element of A is also an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {cell1, cell2} are: {cell1}, {cell2}, and {cell1, cell2}.

[0460] Various examples are disclosed in this specification. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create additional examples within the scope of this disclosure.

[0461] Various examples are disclosed in this specification. Limitations, features, and / or elements from the disclosed example embodiments may be combined to create additional examples within the scope of this disclosure.

[0462] In this specification, a parameter (information element: IE) may include one or more objects, and one of these objects may include one or more other objects. For example, if parameter (IE)N includes parameter (IE)M, and parameter (IE)M includes parameter (IE)K, and parameter (IE)K includes parameter (information element)J, then, for example, N includes K, and N includes J. In one example, when one or more messages include multiple parameters, it means that a parameter among the multiple parameters is present in at least one of the one or more messages, but not necessarily in one of the one or more messages.

[0463] Many of the elements described in the disclosed examples can be implemented as modules. A module is defined herein as a separable element that performs a defined function and has a defined interface to other elements. The modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (i.e., hardware with biological elements), or combinations thereof, some of which are behaviorally equivalent. For example, a module can be implemented as software routines written in a computer language configured to be executed by a hardware machine (e.g., C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (e.g., Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). Alternatively, it is possible to implement modules using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers; microcontrollers; microprocessors; application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, and C++. FPGAs, ASICs, and CPLDs are frequently programmed using hardware description languages ​​(HDLs), such as VHSIC Hardware Description Language (VHDL) or Verilog. These languages ​​configure connections between relatively small internal hardware modules on a programmable device. Finally, it is important to emphasize that the above techniques are often used in combination to achieve the desired functional modules.

[0464] The disclosure of this patent document incorporates copyrighted material. The copyright holder does not object to anyone making an exact copy of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office's patent documents or records for limited purposes required by law, but otherwise reserves all copyright rights.

[0465] Although various examples have been described above, it should be understood that they are presented by way of example rather than limitation. It will be apparent to those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of this disclosure. Indeed, after reading the above description, it will be apparent to those skilled in the art how to implement alternative examples. Therefore, the present examples should not be limited to any of the exemplary examples described above. In particular, it should be noted that for illustrative purposes, the above explanation has focused on examples using 5G AN. However, those skilled in the art will recognize that examples of the invention can be implemented in systems including one or more legacy systems or LTE. The disclosed methods and systems can be implemented in wireless or wired systems. Features of the various examples presented in this invention can be combined. One or more features (methods or systems) of one example can be implemented in other examples. A limited number of example combinations are shown to indicate to those skilled in the art the possibility of combining features from various examples to create enhanced transmission and reception systems and methods.

[0466] Furthermore, it should be understood that any diagrams highlighting features and benefits are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in ways other than those shown. For example, the actions listed in any flowchart can be reordered or used only optionally in certain examples.

[0467] Furthermore, the purpose of this abstract is to enable the U.S. Patent and Trademark Office and the general public, especially scientists, engineers, and practitioners unfamiliar with patent or legal terminology, to quickly determine the nature and substance of the technical disclosure of this application through a cursory examination. This abstract is not intended to limit the scope in any way.

[0468] Finally, the applicant's intention is that only claims including the phrases "apparatus for..." or "steps for..." should be interpreted according to 35 U.SC 112. Claims that do not explicitly include the phrases "apparatus for..." or "steps for..." should not be interpreted according to 35 U.SC 112.

Claims

1. A method for synchronizing multiple data streams, the method comprising: The Session Management Function (SMF) receives from the wireless device and in the message a first parameter indicating a request for synchronization of multiple data streams of the Service Data Session (SDS) and a second parameter indicating a request for establishing the SDS. as well as User plane rules, which are sent by the SMF to the User Plane Function (UPF) and based on the first and second parameters, instruct the UPF to perform synchronous forwarding of packets for the plurality of data streams, wherein the user plane rules include: Time configuration information indicating the timestamp configuration information of the multiple data streams; and At least one of the following: One or more packet detection rules are used for the synchronous forwarding; One or more forwarding action rules are used for the synchronous forwarding; One or more Quality of Service (QoS) enforcement rules are used for the synchronization forwarding; or One or more usage reporting rules are used for the synchronous forwarding.

2. The method of claim 1, further comprising policy control functions and session management functions performed by the SMF.

3. The method of claim 1, wherein the SMF receives the message from the wireless device via a base station.

4. The method of claim 3, wherein the wireless device is associated with each of the plurality of data streams.

5. The method of claim 3, wherein: The wireless device is associated with a first data stream of the plurality of data streams; and The second wireless device is associated with the second data stream of the plurality of data streams.

6. The method of any one of claims 1 to 5, wherein the message comprises at least one of the following: Stream information of the multiple data streams; Holographic communication of the requests for the multiple data streams via HTC network slicing; The HTC data network name DNN for the multiple data streams; and Timestamp information.

7. The method of claim 6, wherein the stream information of the plurality of data streams includes at least one of the following: The stream identifiers of the plurality of data streams; and Stream filter information for the multiple data streams.

8. The method of claim 6, wherein the stream information includes at least one of the following: IP packet filter set; or Ethernet packet filter set.

9. The method of claim 6, wherein the requested HTC network slice indicates that the plurality of data streams of the requested HTC network slice are requested to be synchronized.

10. The method of claim 6, wherein the HTC DNN indicates that the plurality of data streams of the DNN are requested to be synchronized.

11. The method according to any one of claims 1 to 5, further comprising: The SMF determines the user plane rules based on the first parameter and the second parameter.

12. The method of claim 11, wherein the user plane rules are determined based on policies and charging control rules.

13. The method of claim 12, wherein the strategy and charge control rules further include at least one of the following: Fee control rules; Policy control rules, wherein the policy control rules include at least one of the following: Service quality control rules; or Gating control rules; Use monitoring and control rules; Apply detection and control rules; Flow redirection control rules; and Data stream detection information.

14. A session management function (SMF), the SMF including one or more processors and a memory storing instructions, the instructions causing the SMF to perform the method as described in any one of claims 1 to 13 when executed by the one or more processors.

15. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method as described in any one of claims 1 to 13.

Images