Time-sensitive network configuration based on control plane
By introducing network slicing technology and service-based interaction mechanisms in 5G systems, the problem of decoupling network slicing and access network core network functions in 5G systems is solved, and efficient and flexible network management and low-latency services are achieved.
Patent Information
- Application Number
- CN202211405417.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-01-15
- Filing Date
- 2020-01-15
- Publication Date
- 2025-10-17
- Estimated Expiration
- 2040-01-15
AI Technical Summary
The existing 5G system has problems with incomplete functional decoupling in network slicing and access network core network functions, and high dependence between the access network and core network, resulting in low system efficiency and lack of flexibility.
By introducing network slicing technology in the 5G system, the separation of the control plane and the user plane is achieved, and a service-based interaction mechanism is adopted to support aggregated access to an agnostic core network of multiple access types, reducing the dependency between the access network and the core network, and optimizing the network architecture through network function virtualization and software-defined network technology.
It improves the network slicing capability of the 5G system and the flexibility of the access network core network, enhances the efficiency and adaptability of the system, supports unified management of multiple access types, and realizes low-latency services and efficient access to local data networks.
Smart Images

Figure CN115695324B_ABST
Abstract
Description
[0001] Divisional Application
[0002] This application is a divisional application of the application filed on January 15, 2020, having application number 202080009451.5, and titled “Time-Sensitive Network Configuration Based on Control Plane.”
[0003] Cross Reference to Related Applications
[0004] This application claims the benefit of U.S. Provisional Application No. 62 / 792,652, filed on January 15, 2019, which is hereby incorporated by reference in its entirety. BRIEF DESCRIPTION OF DRAWINGS
[0005] Examples of several different embodiments of the present invention are described herein with reference to the accompanying drawings.
[0006] Figure 1 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0007] Figure 2 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0008] Figure 3 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0009] Figure 4 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0010] Figure 5A FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure. Figure 5B FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0011] Figure 6A FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure. Figure 6B FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0012] Figure 7 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0013] Figure 8 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0014] Figure 9 FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure.
[0015] FIG. 1 is a diagram of an exemplary 5G system architecture according to an aspect of embodiments of the present disclosure. Figure 10 is an example call flow according to an aspect of embodiments of the present disclosure.
[0016] Figure 11 is an example call flow according to an aspect of embodiments of the present disclosure.
[0017] Figure 12 is an example call flow according to an aspect of embodiments of the present disclosure.
[0018] Figure 13 is an example call flow according to an aspect of embodiments of the present disclosure.
[0019] Figure 14 is an example diagram according to an aspect of embodiments of the present disclosure.
[0020] Figure 15 is an example diagram according to an aspect of embodiments of the present disclosure.
[0021] Figure 16 is an example diagram according to an aspect of embodiments of the present disclosure.
[0022] Figure 17 is an example diagram according to an aspect of embodiments of the present disclosure.
[0023] Figure 18 is an example diagram according to an aspect of embodiments of the present disclosure.
[0024] Figure 19 is an example diagram according to an aspect of embodiments of the present disclosure.
[0025] Figure 20 is an example diagram according to an aspect of embodiments of the present disclosure.
[0026] Figure 21 is an example diagram according to an aspect of embodiments of the present disclosure.
[0027] Figure 22 is an example call flow according to an aspect of embodiments of the present disclosure.
[0028] Figure 23 is an example call flow according to an aspect of embodiments of the present disclosure.
[0029] Figure 24 is an example call flow according to an aspect of embodiments of the present disclosure.
[0030] Figure 25 is an example call flow according to an aspect of embodiments of the present disclosure.
[0031] Figure 26is an example call flow according to an aspect of embodiments of the present disclosure.
[0032] Figure 27 is an example call flow according to an aspect of embodiments of the present disclosure.
[0033] Figure 28 is an example diagram according to an aspect of embodiments of the present disclosure.
[0034] Figure 29 is an example diagram according to an aspect of embodiments of the present disclosure.
[0035] Figure 30 is an example diagram according to an aspect of embodiments of the present disclosure.
[0036] Figure 31 is an example call flow according to an aspect of embodiments of the present disclosure.
[0037] Figure 32 is an example call flow according to an aspect of embodiments of the present disclosure.
[0038] Figure 33 is an example call flow according to an aspect of embodiments of the present disclosure.
[0039] Figure 34 is an example call flow according to an aspect of embodiments of the present disclosure.
[0040] Figure 35 is an example call flow according to an aspect of embodiments of the present disclosure.
[0041] Figure 36 is an example call flow according to an aspect of embodiments of the present disclosure.
[0042] Figure 37 is an example call flow according to an aspect of embodiments of the present disclosure. DETAILED DESCRIPTION
[0043] Example embodiments of the present invention can implement enhanced features and functions in a 5G system. Embodiments of the technology disclosed herein can apply to the field of network slicing technology for 5G systems and communication systems. More specifically, embodiments of the technology disclosed herein can relate to a 5G core network and 5G system for network slicing in a communication system. Throughout the present disclosure, UE, wireless device, and mobile device can be used interchangeably.
[0044] The following abbreviations are used throughout the present disclosure:
[0045] 5G Fifth generation mobile network
[0046] 5GC 5G core network
[0047] 5GS 5G system
[0048] 5G-AN 5G access network
[0049] 5QI 5G QoS indicator
[0050] AF application function
[0051] AMF access and mobility management function
[0052] AN access network
[0053] CDR charging data record
[0054] CCNF common control network function
[0055] CIoT cellular internet of things
[0056] CN core network
[0057] CP control plane
[0058] DDN downlink data notification
[0059] DL downlink
[0060] DN data network
[0061] DNN data network name
[0062] F-TEID full qualified TEID
[0063] GPSI generic public subscription identifier
[0064] GTP GPRS tunneling protocol
[0065] GUTI globally unique temporary identifier
[0066] IMSI international mobile subscriber identity
[0067] LADN local area data network
[0068] LI lawful interception
[0069] MEI mobile equipment identifier
[0070] MICO mobile terminal initiated connection only
[0071] MME mobility management entity
[0072] MO mobile originating
[0073] MSISDN mobile subscriber ISDN
[0074] MT mobile station being called
[0075] N3IWF non-3GPP interworking function
[0076] NAI network access identifier
[0077] NAS non-access stratum
[0078] NB-IoT narrow band internet of things
[0079] NEF network exposure function
[0080] NF network function
[0081] NGAP next generation application protocol
[0082] NR new radio
[0083] NRF network repository function
[0084] NSI network slice instance
[0085] NSSAI network slice selection assistance information
[0086] NSSF network slice selection function
[0087] OCS online charging system
[0088] OFCS offline charging system
[0089] PCF policy control function
[0090] PDU packet / protocol data unit
[0091] PEI permanent equipment identifier
[0092] PLMN public land mobile network
[0093] RAN radio access network
[0094] QFI QoS flow identity
[0095] RM registration management
[0096] S1-AP S1 application protocol
[0097] SBA service-based architecture
[0098] SEA security anchor function
[0099] SCM security context management
[0100] SMF session management function
[0101] SMSF SMS function
[0102] S-NSSAI single network slice selection assistance information
[0103] SUCI served user association ID
[0104] SUPI subscriber permanent identifier
[0105] TEID tunnel endpoint identifier
[0106] TSN time sensitive network
[0107] UE user equipment
[0108] UL uplink
[0109] UL CL uplink classifier
[0110] UPF user plane function
[0111] Exemplary Figure 1 And Figure 2 A 5G system is depicted consisting of an access network and a 5G core network. An exemplary 5G access network can include an access network connected to a 5G core network. The access network can include an NG-RAN 105 and / or a non-3GPP AN 165. An exemplary 5G core network can be connected to one or more 5G access networks 5G-AN and / or NG-RAN. The 5G core network can include functional elements or network functions as depicted in Figure 1 And exemplary Figure 2 The interfaces can be used for communication between the functional elements and / or network elements.
[0112] In one example, a network function can be a processing function in a network, which can have functional behavior and / or interfaces. The network function can be implemented as a network element on dedicated hardware, and / or as a software instance running on dedicated hardware and / or shared hardware, or as a virtualized function instantiated on an appropriate platform, as depicted in Figure 3 And Figure 4
[0113] In one example, the access and mobility management function, AMF 155, can include the following functions (some of the AMF 155 functions can be supported in a single instance of the AMF 155): termination of RAN 105 CP interface (N2), termination of NAS (Nl), NAS ciphering and integrity protection, registration management, connection management, reachability management, mobility management, lawful intercept (interface to LI system for AMF 155 events), transport for subscription management, SM messages between the UE 100 and the SMF 160, transparent proxy for routing SM messages, access authentication, access authorization, transport for SMS messages between UE 100 and SMSF, interaction with the AUSF 150 and the security anchor function, SEA, for security anchor functionality with UEs 100, receive intermediate keys established as a result of UE 100 authentication, security context management, SCM, receive keys from the SEA for derivation of access-network specific keys, etc.
[0114] In one example, the AMF 155 can support non-3GPP access networks through N2 interface with N3IWF 170, through NAS signaling with UEs 100 over N3IWF 170, authentication of UEs connected through N3IWF 170, mobility management, separate security context state for UEs 100 connected via non-3GPP access 165 or simultaneously connected via 3GPP access 105 and non-3GPP access 165, support of coordinated RM context valid through 3GPP access 105 and non-3GPP access 165, support of CM management context for UEs 100 for connection through non-3GPP access, etc.
[0115] In one example, the AMF 155 region can include one or more AMF 155 sets. An AMF 155 set can include some AMF 155 that serve a given region and / or network slice. In one example, multiple AMF 155 sets can be based on AMF 155 regions and / or network slices. An application identifier can be an identifier that can be mapped to a specific application traffic detection rule. A configured NSSAI can be an NSSAI that can be provided in the UE 100. For a DNN, a DN 115 access identifier (DNAI) can be an identifier of a user plane access DN 115. An initial registration can relate to a UE 100 registration in an RM-DEREGISTERED 500, 520 state. An N2AP UE 100 association can be a logical based UE 100 association between a 5G AN node and an AMF 155. An N2AP UE-TNLA binding can be a binding between an N2AP UE 100 association and a specific transport network layer, TNL, association for a given UE 100.
[0116] In one example, the Session Management Function, SMF 160, can include one or more of the following functions (one or more of the SMF 160 functions can be supported in a single instance of the SMF 160): session management (e.g., session establishment, modify, 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 function, configuring traffic steering at the UPF 110 to route traffic to proper destination, termination of policy control function interface, policy enforcement and QoS control, lawful intercept (interfaces to SM events and LI system), termination of SM part of NAS messages, downlink data notification, initiation of AN specific SM information, transmission to (R)AN 105 over N2 via AMF 155, determination of SSC mode of a session, roaming functionality, handling local enforcement to apply QoS SLAs (VPLMN), charging data collection and charging interface (VPLMN), lawful intercept (interfaces to SM events and LI system in VPLMN), support for interaction with external DN 115 for transport of signaling via external DN 115, etc. for PDU session authorization / authentication.
[0117] In one example, the User Plane Function, UPF 110, can include one or more of the following functions (some of the UPF 110 functions can be supported in a single instance of the UPF 110): anchor point for Intra- / Inter-RAT mobility (as applicable), external PDU session point of interconnect to DN 115, packet routing and forwarding, user plane part of packet inspection and policy rule enforcement, lawful intercept (UP collection), traffic usage reporting, uplink classifier to support routing traffic flows to the data network, branching point to support multi-homed PDU session, QoS handling for user plane, uplink traffic verification (SDF to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering, downlink data notification triggering, etc.
[0118] In one example, UE 100 IP address management can include allocation and release of UE 100 IP addresses and / or update of allocated IP addresses. The UE 100 can set the requested PDU type during the PDU session establishment procedure based on its IP stack capabilities and / or configuration. In one example, the SMF 160 can select the PDU type for the PDU session. In one example, if the SMF 160 receives a request with PDU type set to IP, the SMF 160 can select the PDU type IPv4 or IPv6 based on the DNN configuration and / or operator policy. In one example, the SMF 160 can provide a cause value to the UE 100 to indicate whether the other IP version is supported on the DNN. In one example, if the SMF 160 receives a request for PDU type IPv4 or IPv6 and the requested IP version is supported by the DNN, the SMF 160 can select the requested PDU type.
[0119] In example embodiments, 5GC elements and the UE 100 can support the following mechanisms: during the PDU session establishment procedure, the SMF 160 can 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 via DHCPv4 can be employed. If IPv6 is supported, IPv6 prefix allocation can be supported via IPv6 stateless auto-configuration. For example, 5GC network elements can support IPv6 parameter configuration via stateless DHCPv6.
[0120] The 5GC can support allocation of static IPv4 addresses and / or static IPv6 prefixes based on subscription information in the UDM 140 and / or per-subscriber, per-DNN configured.
[0121] The user plane function (UPF 110) can handle the user plane path of the PDU session. The UPF 110 that provides an interface to data networks can support the function of a PDU session anchor point.
[0122] In one example, the policy control function PCF 135 can support a unified policy framework to govern network behavior, provide policy rules to control plane functions to enforce policy rules, implement a front end to access subscription information related to policy decisions in a user data repository (UDR), and / or the like.
[0123] The network exposure function NEF 125 can provide a means to securely expose services and capabilities offered by 3GPP network functions, translate between information exchanged with an AF 145 and information exchanged with internal network functions, receive information from other network functions, and / or the like.
[0124] In one example, the Network Repository Function, NRF 130, can support a service discovery function that can receive NF discovery requests from NF instances, provide information about discovered NF instances (discovered) to NF instances, and maintain information about available NF instances and their supported services, etc.
[0125] In one example, the NSSF 120 can select a set of network slice instances that serve the UE 100, can determine allowed NSSAI. In one example, the NSSF 120 can determine a set of AMF 155 for providing service for the UE 100 and / or determine a list of candidate AMF 155 155 by querying the NRF 130 based on a configuration.
[0126] In one example, data stored in the UDR can include at least user subscription data including at least subscription identifier, security credentials, access and mobility related subscription data, session related subscription data, policy data, etc.
[0127] In one example, the AUSF 150 can support an Authentication Server Function (AUSF 150).
[0128] In one example, the Application Function, AF 145, can interact with the 3GPP core network to provide services. In one example, based on operator deployment, an application function can gain operator trust to directly interact with relevant network functions. An application function that is not allowed direct access to network functions can interact with relevant network functions using an external exposure framework (e.g., via the NEF 125).
[0129] In one example, the control plane interface between the (R)AN 105 and the 5G core can support connecting multiple different types of ANs (e.g., 3GPP RAN 105, N3IWF 170 for untrusted access 165) to the 5GC via the control plane protocol. In one example, the N2 AP protocol can be used for both 3GPP access 105 and non-3GPP access 165. In one example, the control plane interface between the (R)AN 105 and the 5G core can support decoupling between the AMF 155 and other functions such as the SMF 160 that can need to control services supported by the AN (e.g., control resources in the UP AN 105 for a PDU session).
[0130] In one example, the 5GC may provide policy information from the PCF 135 to the UE 100. In one example, the 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 offload policy, etc.
[0131] In one example, as shown in the example Figure 5A and Figure 5B As depicted, the Registration Management RM may be used to register or deregister the UE / user 100 with the network and establish a user context in the network. Connection management may be employed to establish and release a signaling connection between the UE 100 and the AMF 155.
[0132] In one example, UE 100 may register with the network to receive services requiring registration. In one example, UE 100 may periodically update its registration with the network to remain reachable (periodic registration update), or based on mobility (e.g., mobility registration update), or to update its capabilities or renegotiate protocol parameters.
[0133] In the example, as shown in the example Figure 8 and Figure 9 The depicted initial registration flow may involve the execution of network access control functions (e.g., user authentication and access authorization based on subscription profiles in the UDM 140). Figure 9 yes Figure 8 As a result of the initial registration process, the identity of the serving AMF 155 may be registered in the UDM 140 .
[0134] In one example, the Registration Management, RM, procedure may be applicable to both 3GPP access 105 and non-3GPP access 165 .
[0135] Exemplary Figure 5AThe RM states of the UE 100 observed by the UE 100 and the AMF 155 can be depicted. In example embodiments, two RM states that can reflect the registration status of the UE 100 in a selected PLMN can be employed in the UE 100 and the AMF 155: RM-DEREGISTERED 500 and RM-REGISTERED 510. In one example, in the RM DEREGISTERED state 500, the UE 100 can not be registered with the network. The UE 100 context in the AMF 155 can not hold a valid location or routing information for the UE 100, so the UE 100 can not be reachable by the AMF 155. In one example, the UE 100 context can be stored in the UE 100 and the AMF 155. In one example, in the RM REGISTERED state 510, the UE 100 can be registered with the network. In the RM-REGISTERED 510 state, the UE 100 can receive services that can require registration with the network.
[0136] In example embodiments, two RM states that can reflect the registration status of the UE 100 in a selected PLMN can be employed in the AMF 155 for the UE 100: RM-DEREGISTERED 520 and RM-REGISTERED 530.
[0137] As depicted in example Figure 6A and Figure 6B As depicted, the connection management, CM, can include establishment and release of a signaling connection between the UE 100 and the AMF 155 over the N1 interface. The signaling connection can be employed to enable NAS signaling exchange between the UE 100 and the core network. The signaling connection between the UE 100 and the AMF 155 can include an AN signaling connection between the UE 100 and the (R)AN 105 (e.g., RRC connection over 3GPP access) and an N2 connection between the AN for the UE 100 and the AMF 155.
[0138] As depicted in example Figure 6A and Figure 6B Two CM states can be used for the UE 100 NAS signaling connection with the AMF 155, CM-IDLE 600, 620 and CM-CONNECTED 610, 630. A UE 100 in the CM-IDLE 600 state can be in the RM-REGISTERED 510 state and can not have a NAS signaling connection established with the AMF 155 over N1. The UE 100 can perform cell selection, cell reselection, PLMN selection, etc. A UE 100 in the CM-CONNECTED 610 state can have a NAS signaling connection with the AMF 155 over N1.
[0139] In an example implementation, two CM states can be employed at the AMF 155, CM-IDLE 620, and CM-CONNECTED 630 for the UE 100.
[0140] In one example, the RRC Inactive state can be applied to NG-RAN (e.g., it can be applied to NR and E-UTRA connected to 5G CN). Based on network configuration, the AMF 155 can provide assistance information to the NG RAN 105 to help the NG RAN 105 decide whether the UE 100 can be sent as RRC Inactive state. When the UE 100 is in CM-CONNECTED 610 in RRC Inactive state, the UE 100 can resume RRC connection due to uplink data pending, mobile originated signaling procedure, in response to RAN 105 paging, to inform the network that it has left the RAN 105 notification area, etc.
[0141] In one example, NAS signaling connection management can include establishment and release of NAS signaling connection. NAS signaling connection establishment function can be provided by the UE 100 and the AMF 155 in order to establish a NAS signaling connection for the UE 100 in CM-IDLE 600 state. The procedure to release the NAS signaling connection can be initiated by the 5G (R)AN 105 node or the AMF 155.
[0142] In one example, reachability management of the UE 100 can detect whether the UE 100 is reachable and can provide the network with a location (e.g., access node) of the UE 100 to reach the UE 100. Reachability management can be accomplished by paging the UE 100 and UE 100 location tracking. The UE 100 location tracking can include both UE 100 registration area tracking and UE 100 reachability tracking. The UE 100 and the AMF 155 can negotiate the UE 100 reachability characteristics for the UE 100 in CM-IDLE 600, 620 state during the registration and registration update procedures.
[0143] In one example, for CM-IDLE 600, 620 state, two UE 100 reachability categories can be negotiated between the UE 100 and the AMF 155. 1) UE 100 reachability allows mobile device termination of data when the UE 100 is in CM-IDLE 600 mode. 2) Mobile initiated connection only (MICO) mode. The 5GC can support a PDU connectivity service that provides exchange of PDUs between the UE 100 and a data network identified by a DNN. The PDU connectivity service can be supported via a PDU session established upon request from the UE 100.
[0144] In one example, a PDU session can support one or more PDU session types. A PDU session 160 can be established (e.g., upon request by the UE 100), modified (e.g., upon request by the UE 100 and 5GC), and / or released (e.g., upon request by the UE 100 and 5GC) using NAS SM signaling exchanged between the UE 100 and the SMF over N1. Upon request from an application server, the 5GC can be able to trigger a specific application in the UE 100. When the trigger is received, the UE 100 can send it to an identified application in the UE 100. The application represented in the UE 100 can establish a PDU session with a specific DNN.
[0145] In one example, the 5G QoS model can support a QoS flow based framework, as exemplified in FIG. 7. The 5G QoS model can support QoS flows that require guaranteed flow bit rates and QoS flows that can not require guaranteed flow bit rates. In one example, the 5G QoS model can support reflective QoS. The QoS model can include flow mapping or packet marking at the UPF 110 (CN UP) 110, the AN 105, and / or the UE 100. In one example, the packets can be from and / or to the application / service layer 730 of the UE 100, the UPF 110 (CN UP) 110, and / or the AF 145. Figure 7
[0146] In one example, a QoS flow can be the granularity of QoS differentiation in a PDU session. A QoS flow ID, QFI, can be used to identify a QoS flow in the 5G system. In one example, user plane traffic with the same QFI within a PDU session can receive the same traffic forwarding treatment. The QFI can be carried in encapsulation headers over N3 and / or N9 (e.g., without any changes to the end-to-end packet header). In one example, a QFI can be applied to PDUs with different types of payloads. The QFI can be unique in a PDU session.
[0147] In one example, QoS parameters for a QoS flow can be provided to the (R)AN 105 as a QoS profile at PDU session establishment, at QoS flow establishment, or at each time the user plane is activated using the NG-RAN over N2. In one example, each PDU session can need a default QoS rule. The SMF 160 can allocate a QFI for a QoS flow and can derive QoS parameters from information provided by the PCF 135. In one example, the SMF 160 can provide the QFI to the (R)AN 105 together with a QoS profile containing QoS parameters for the QoS flow.
[0148] In one example, a 5G QoS flow can be the granularity of QoS forwarding treatment in a 5G system. Traffic mapped to the same 5G QoS flow can receive the same forwarding treatment (e.g., scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.). In one example, providing different QoS forwarding treatment can require separate 5G QoS flows.
[0149] In one example, a 5G QoS indicator can be a scalar that can be used as a reference to a specific QoS forwarding behavior (e.g., packet loss rate, packet delay budget) that will be provided to a 5G QoS flow. In one example, a 5G QoS indicator can be implemented in an access network through 5QI reference node-specific parameters that can control QoS forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).
[0150] In one example, a 5GC can support edge computing and can enable operators and 3rd party services to be hosted close to the UE's point of attachment to the network. The 5G core network can select a UPF 110 close to the UE 100 and can perform traffic steering from the UPF 110 to local data networks via an N6 interface. In one example, the selection and traffic steering can be based on subscription data of the UE 100, UE 100 location, information from application functions AF 145, policies, other relevant traffic rules, etc. In one example, the 5G core network can expose network information and capabilities to edge computing application functions. The functional support for edge computing can include: local breakout, where the 5G core network can select a UPF 110 to route user traffic to a local data network; traffic steering, where the 5G core network can select traffic to be routed to applications in a local data network; session and service continuity to enable UE 100 and application mobility; user plane selection and reselection, e.g., based on input from application functions; network capability exposure, where the 5G core network and application functions can provide information for each other via NEf 125; QoS and charging, where the PCF 135 can provide rules for QoS control and charging for traffic routed to a local data network; support for local area data networks, where the 5G core network can support LADN connected to a certain area where applications are deployed, etc.
[0151] An example 5G system can be a 3GPP system including a 5G access network 105, a 5G core network, and a UE 100, etc. Allowed NSSAI can be an NSSAI provided by a serving PLMN during, for example, a registration procedure, indicating a network allowed NSSAI for the UE 100 in the serving PLMN for the current registration area.
[0152] In one example, a PDU connectivity service can provide exchange of PDUs between the UE 100 and a data network. A PDU session can be an association between the UE 100 and a data network DN 115 that can provide a PDU connectivity service. The association type can be IP, Ethernet, and / or unstructured.
[0153] Establishing a user plane connection to a data network via a network slice instance can include the following operations: performing a RM procedure to select an AMF 155 that supports a required network slice, and establishing one or more PDU sessions to a required data network via the network slice instance.
[0154] In one example, a set of network slices for the UE 100 can change at any time when the UE 100 can register with the network, and can be initiated by the network or the UE 100.
[0155] In one example, a periodic registration update can be a re-registration of the UE 100 when a periodic registration timer expires. The requested NSSAI can be an NSSAI that the UE 100 can provide to the network.
[0156] In one example, a service-based interface can represent the way a given NF can provide / expose a set of services.
[0157] In one example, service continuity can be an uninterrupted user experience of a service, including cases where the IP address and / or anchor point can change. In one example, session continuity can refer to continuity of a PDU session. For IP type PDU sessions, session continuity can mean that the IP address is preserved for the lifetime of the PDU session. An uplink classifier can be a UPF 110 function that aims to divert uplink traffic to a data network DN 115 based on filtering rules provided by the SMF 160.
[0158] In one example, a 5G system architecture can support data connectivity and services, enabling deployments to use technologies such as network function virtualization and / or software defined networking. The 5G system architecture can utilize service-based interaction between identified control plane (CP) network functions. In the 5G system architecture, user plane (UP) functions can be considered separate from control plane functions. If needed, the 5G system can enable network functions to directly interact with other NFs.
[0159] In one example, a 5G system can reduce dependencies between an access network (AN) and a core network (CN). The architecture can include an aggregated access agnostic core network with a generic AN-CN interface that can integrate different 3GPP and non-3GPP access types.
[0160] In one example, a 5G system can support a unified authentication framework, stateless NFs, where compute resources are separated from storage resources, capability exposure, and concurrent access to local and centralized services. To support low latency services and access to local data networks, UP functions can be deployed close to the access network.
[0161] In one example, a 5G system can support roaming using home network routing traffic and / or local breakout traffic in visited PLMNs. An example 5G architecture can be service-based and interactions between network functions can be represented in two ways. (1) As a service-based representation (depicted in an example Figure 1
[0162] In one example, a network slice can include core network control plane and user plane network functions, a 5G radio access network; N3IWF acting on non-3GPP access networks and / or the like. Network slices can differ in supported features and network function implementations. An operator can deploy multiple network slice instances providing the same features but targeted for different groups of UEs, e.g., because they offer different committed services and / or because they can be committed to serve customers. The NSSF 120 can store mapping information between slice instance IDs and NF IDs (or NF addresses).
[0163] In one example, a UE 100 can be simultaneously served by one or more network slice instances via a 5G-AN. In one example, a UE 100 can be served by k network slices at a time (e.g., k = 8, 16, etc.). An AMF 155 instance logically serving the UE 100 can belong to a network slice instance serving the UE 100.
[0164] In one example, a PDU session can belong to one particular network slice instance based on a PLMN. In one example, different network slice instances can not share a PDU session. Different slices can have slice-specific PDU sessions using the same DNN.
[0165] An S-NSSAI (Single-Network Slice Selection Assistance Information) can identify a network slice. An S-NSSAI can include a slice / service type (SST), which can refer to an intended network slice behavior in terms of features and services, and / or a slice differentiator (SD). The slice differentiator can be optional information that can complement the slice / service type to allow further differentiation to select a network slice instance from possibly multiple network slice instances that conform to the indicated slice / service type. In one example, different S-NSSAIs can be employed to select the same network slice instance. The CN part of the network slice instance serving the UE 100 can be selected by the CN.
[0166] In one example, the subscription data can include S-NSSAIs of network slices to which the UE 100 is subscribed. One or more S-NSSAIs can be marked as a default S-NSSAI. In one example, k S-NSSAIs can be marked as default S-NSSAIs (e.g., k = 8, 16, etc.). In one example, the UE 100 can subscribe to more than 8 S-NSSAIs.
[0167] In one example, the UE 100 can be configured by the HPLMN with a PLMN-based configured NSSAI. Upon successful completion of the registration procedure of the UE, the UE 100 can obtain from the AMF 155 an allowed NSSAI for that PLMN, which can include one or more S-NSSAIs.
[0168] In one example, the priority of the allowed NSSAI can be higher than the configured NSSAI of the PLMN. The UE 100 can use the S-NSSAIs in the allowed NSSAI corresponding to network slices for subsequent network slice selection related procedures in the PLMN in which the UE 100 is served.
[0169] In one example, the priority of the allowed NSSAI can be higher than the configured NSSAI of the PLMN. The UE 100 can use the S-NSSAIs in the allowed NSSAI corresponding to network slices for subsequent network slice selection related procedures in the PLMN in which the UE 100 is served.
[0170] In one example, establishing a user plane connection to a data network via a network slice instance can include performing a RM procedure to select an AMF 155 that can support a required network slice, establishing one or more PDU sessions with a required data network via the network slice instance, etc.
[0171] In one example, when the UE 100 registers with a PLMN, if the UE 100 has a configured NSSAI or an allowed NSSAI for the PLMN, the UE 100 can provide to the network in the RRC and NAS layers a requested NSSAI including S-NSSAIs corresponding to slices that the UE 100 attempts to register, a temporary user ID if the UE is assigned one, etc. The requested NSSAI can be a configured NSSAI, an allowed NSSAI, etc.
[0172] In one example, when the UE 100 registers with a PLMN, if the UE 100 has no configured NSSAI or allowed NSSAI for the PLMN, the RAN 105 can route NAS signaling from the UE 100 to a default AMF 155 or from the default AMF to the UE.
[0173] In one example, based on local policies, subscription changes, and / or UE 100 mobility, the network can change the set of allowed network slices that the UE 100 is registered to. In one example, the network can perform the change during a registration procedure or trigger a change of supported network slices to the UE 100 using a RM procedure (which can trigger a registration procedure). The network can provide the UE 100 with a new allowed NSSAI and a list of tracking areas.
[0174] In one example, during a registration procedure in a PLMN, if the network decides based on network slicing aspects that the UE 100 can be served by a different AMF 155, the AMF 155 that first receives the registration request can redirect the registration request to another AMF 155 via the RAN 105 or via direct signaling between the initial AMF 155 and the target AMF 155.
[0175] In one example, the network operator can provide the UE 100 with a network slice selection policy (NSSP). The NSSP can include one or more NSSP rules.
[0176] In one example, if the UE 100 has one or more PDU sessions established corresponding to a particular S-NSSAI, the UE 100 can route the user data of an application in one of the PDU sessions unless other conditions in the UE 100 can prohibit the use of the PDU session. If the application provides a DNN, the UE 100 can consider the DNN to determine which PDU session to use. In one example, if the UE 100 does not have a PDU session established with a particular S-NSSAI, the 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 one example, for the RAN 105 to select appropriate resources to support network slices in the RAN 105, the RAN 105 can be aware of the network slices used by the UE 100.
[0177] In one example, when the UE 100 triggers establishment of a PDU session, the AMF 155 can select an SMF 160 in a network slice instance based on S-NSSAI, DNN, and / or other information such as UE 100 subscription and local operator policy, etc. The selected SMF 160 can establish the PDU session based on S-NSSAI and DNN.
[0178] In one example, to support network-controlled privacy of slice information that the UE 100 can access, the UE 100 can not include NSSAI in NAS signaling unless the UE 100 has a NAS security context and the UE 100 can not include NSSAI in unprotected RRC signaling when the UE 100 is aware or configured that privacy considerations can apply to the NSSAI.
[0179] In one example, for roaming scenarios, network slice-specific network functions in the VPLMN and HPLMN can be selected based on S-NSSAI provided by the UE 100 during PDU connection establishment. If standardized S-NSSAI is used, selection of slice-specific NF instances can be done by one or more PLMNs based on the provided S-NSSAI. In one example, the VPLMN can map S-NSSAI of the HPLMN to S-NSSAI of the VPLMN (e.g., including mapping to a default S-NSSAI of the VPLMN) based on roaming agreements. In one example, selection of slice-specific NF instances in the VPLMN can be done based on S-NSSAI of the VPLMN. In one example, selection of any slice-specific NF instances in the HPLMN can be based on S-NSSAI of the HPLMN.
[0180] As depicted in example Figure 8 and Figure 9 , a registration procedure can be performed by the UE 100 to be authorized to receive services, enable mobility tracking, enable reachability, etc.
[0181] In one example, the UE 100 can send an AN message 805 (including AN parameters, RM-NAS registration request (registration type, SUCI or SUPI or 5G-GUTI, last visited TAI (if available), security parameters, requested NSSAI, mapping of requested NSSAI, UE 100 5GC capabilities, PDU session status, PDU sessions to be reactivated, follow on request, MICO mode preference, etc.), etc.) to the (R)AN 105. In one example, in the case of NG-RAN, the AN parameters can include, for example, SUCI or SUPI or 5G-GUTI, selected PLMN ID and requested NSSAI, etc. In one example, the AN parameters can include an establishment cause. The establishment cause can provide a reason for requesting establishment of an RRC connection. In one example, the registration type can indicate whether the UE 100 wants to perform an initial registration (i.e., the UE 100 is in an RM-REGISTERED state), a mobility registration update (e.g., the UE 100 is in an RM-REGISTERED state and initiates a registration procedure due to mobility), a periodic registration update (e.g., the UE 100 is in an RM-REGISTERED state and can initiate a registration procedure due to periodic registration update timer expiry), or an emergency registration (e.g., the UE 100 is in a limited service state). In one example, if the UE 100 performs an initial registration to a PLMN for which the UE 100 does not yet have a 5G-GUTI (i.e., the UE 100 is in an RM-DEREGISTERED state), the UE 100 can include its SUCI or the SUPI in the registration request. The SUCI can be included if the home network has provided a public key to protect the SUPI in the UE. If the UE 100 receives a UE 100 configuration update command indicating that the UE 100 needs to re-register and the 5G-GUTI is invalid, the UE 100 can perform an initial registration and can include the SUPI in the registration request message. For an emergency registration, the SUPI can be included if the UE 100 does not have a valid 5G-GUTI available; the PEI can be included when the UE 100 does not have a SUPI and no valid 5G-GUTI. In other cases, the 5G-GUTI can be included and it can indicate the last serving AMF 155. If the UE 100 has registered in a PLMN (e.g., not the registered PLMN or an equivalent PLMN of the registered PLMN) via non-3GPP access different from 3GPP access, the UE 100 can not provide the 5G-GUTI assigned by the AMF 155 through 3GPP access during the registration procedure over non-3GPP access.If the UE 100 is already registered in a PLMN (e.g., a registered PLMN) different from the new PLMN of the non-3GPP access (i.e., not the registered PLMN or the equivalent PLMN of the registered PLMN) via 3GPP access, the UE 100 can not provide the 5G-GUTI assigned by the AMF 155 over the non-3GPP access during the registration procedure over 3GPP access. The UE 100 can provide the UE's usage settings based on its configuration. In case of initial registration or mobility registration update, the UE 100 can include a mapping of the requested NSSAI, which can be one or more S-NSSAIs of the requested NSSAI to S-NSSAIs of the configured NSSAI for the HPLMN, to ensure that the network is able to verify whether the S-NSSAIs in the requested NSSAI are permitted based on the subscribed S-NSSAIs. If available, the last visited TAI can be included in order to help the AMF 155 to produce the registration area for the UE. In one example, security parameters can be used for authentication and integrity protection. The requested NSSAI can indicate the network slice selection assistance information. The PDU session status can indicate previously established PDU sessions in the UE. When the UE 100 is connected to two AMFs 155 belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status can indicate established PDU sessions for the current PLMN in the UE. The PDU sessions to be reactivated can be included to indicate that the UE 100 can intend to activate PDU sessions for UP connectivity. When the UE 100 is outside the available area of a LADN, the PDU session corresponding to the LADN can not be included in the PDU sessions to be reactivated. When the UE 100 can have pending uplink signaling and the UE 100 can not include the PDU sessions to be reactivated, a subsequent request can be included or the registration type can indicate that the UE 100 can want to perform an emergency registration.
[0182] In one example, if the SUPI or the 5G-GUTI is included or does not indicate a valid AMF 155, the (R)AN 105 can select 808 an AMF 155 based on the (R)AT and the requested NSSAI, if available. If the UE 100 is in CM-CONNECTED state, the (R)AN 105 can forward the registration request message to the AMF 155 based on the UE's N2 connection. If the (R)AN 105 can not select a suitable AMF 155, it can forward the registration request to an AMF 155 configured in the (R)AN 105 to perform the AMF 155 selection 808.
[0183] In one example, the (R)AN 105 can send an N2 message 810 (including: N2 parameters, RM-NAS registration request (registration type, SUPI or 5G-GUTI, last visited TAI (if available), security parameters, requested NSSAI, mapping of requested NSSAI, UE 100 5GC capabilities, PDU session status, PDU sessions to be reactivated, follow-up request, and MICO mode preference), etc.) to the new AMF 155. In one example, when NG-RAN is used, the N2 parameters can include the selected PLMN ID, location information, cell identity, and RAT type related to the cell in which the UE 100 is camped. In one example, when NG-RAN is used, the N2 parameters can include the establishment cause.
[0184] In one example, the new AMF 155 can send a 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 on the old AMF 155 including the full registration request IE, which can be integrity protected, for requesting the SUPI and MM context of the UE. The old AMF 155 can use the integrity protected full registration request IE to verify that the context transfer service operation invocation corresponds to the requested UE 100. In one example, the old AMF 155 can transfer event subscription information for the UE to the new AMF 155 by one or more NF consumers. In one example, the SUPI request can be skipped if the UE 100 identifies itself with a PEI.
[0185] In one example, the old AMF 155 can send a response 815 to Namf_Communication_UEContextTransfer (SUPI, MM Context, SMF 160 information, PCF ID) to the new AMF 155. In one example, the old AMF 155 can respond to the new AMF 155 invoking Namf_Communication_UEContextTransfer by including the SUPI of the UE and the MM Context. In one example, the old AMF 155 can include SMF 160 information including S-NSSAI, SMF 160 identity, and PDU Session ID if the old AMF 155 maintains information about established PDU Sessions. In one example, the old AMF 155 can include information about the NGAP UE-TNLA binding if the old AMF 155 maintains information about active NGAP UE-TNLA bindings to N3IWF.
[0186] In one example, if the SUPI is not provided by the UE 100 nor retrieved from the old AMF 155, the identity request procedure 820 can be initiated by the AMF 155 sending an identity request message to the UE 100 to request a SUCI.
[0187] In one example, the UE 100 can respond with an identity response message 820 including a SUCI. The UE 100 can derive the SUCI by using the provided public key of the HPLMN.
[0188] In one example, the AMF 155 can decide to initiate UE 100 authentication 825 by invoking the AUSF 150. The AMF 155 can select the AUSF 150 based on the SUPI or the SUCI. In one example, if the AMF 155 is configured to support emergency registration of unauthenticated SUPI and the UE 100 indicates a registration type of emergency registration, the AMF 155 can skip authentication and security setup or the AMF 155 can accept that authentication can fail and can continue the registration procedure.
[0189] In one example, authentication 830 can be performed by the Nudm_UEAuthenticate_Get operation. The AUSF 150 can discover the UDM 140. In case the AMF 155 provided the SUCI to the AUSF 150, the AUSF 150 can return the SUPI to the AMF 155 after the authentication is successful. In one example, if network slicing is used, the AMF 155 can decide if the registration request needs to be rerouted, where the initial AMF 155 refers to the AMF 155. In one example, the AMF 155 can initiate NAS security functions. In one example, after completing the NAS security functions setup, the AMF 155 can initiate an NGAP procedure to enable the 5G-AN to use it to protect procedures with the UE. In one example, the 5G-AN can store the security context and can acknowledge to the AMF 155. The 5G-AN can use the security context to protect messages exchanged with the UE.
[0190] In one 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 inform the old AMF 155 that the registration of the UE 100 in the new AMF 155 can be completed by invoking the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication / security procedure failed, the registration can be rejected and the new AMF 155 can invoke the Namf_Communication_RegistrationCompleteNotify service operation with a rejection indication cause code to the old AMF 155. The old AMF 155 can continue as if it never received the UE 100 context transfer service operation. If one or more S-NSSAI that was in use in the old registration area can not be served in the target registration area, the new AMF 155 can determine which PDU sessions can not be supported in the new registration area. The new AMF 155 can invoke the Namf_Communication_RegistrationCompleteNotify service operation including the rejected PDU session IDs and the rejection reason to the old AMF 155 (e.g., S-NSSAI became unavailable). The new AMF 155 can modify the PDU session status accordingly. The old AMF 155 can inform the corresponding SMF 160 to release the UE’s SM context locally by invoking the Nsmf_PDUSession_ReleaseSMContext service operation.
[0191] In one example, the new AMF 155 can send an identity request / response 840 (e.g., PEI) to the UE 100. If the PEI is neither provided by the UE 100 nor retrieved from the old AMF 155, the identity request procedure can be initiated by the AMF 155 sending an identity request message to the UE 100 to retrieve the PEI. The PEI can be transmitted encrypted unless the UE 100 performs emergency registration and can not be authenticated. For emergency registration, the UE 100 can have included the PEI in the registration request.
[0192] In one example, the new AMF 155 can initiate the ME identity check 845 by invoking the N5g-eir_EquipmentIdentityCheck_Get service operation 845.
[0193] In one example, the new AMF 155 can select 905 the UDM 140 based on the SUPI. The UDM 140 can select a UDR instance. In one example, the AMF 155 can select the UDM 140.
[0194] In one example, if the AMF 155 has changed since the last registration procedure, or if the SUPI provided by the UE 100 can not refer to a valid context in the AMF 155, or if the UE 100 registers to the same AMF 155 that it has registered to for non-3GPP access (e.g., the UE 100 is registered over non-3GPP access and can initiate the registration procedure to add 3GPP access), the new AMF 155 can register to the UDM 140 using Nudm_UECM_Registration 910 and can subscribe to be notified when the UDM 140 can deregister the AMF 155. The UDM 140 can store the AMF 155 identity associated with the access type and can not remove the AMF 155 identities associated with other access types. The UDM 140 can store the information provided at registration in the UDR through Nudr_UDM_Update. In one example, the AMF 155 can use Nudm_SDM_Get 915 to retrieve the access and mobile subscription data and the SMF 160 selection subscription data. The UDM 140 can retrieve this information from the UDR through Nudr_UDM_Query (access and mobile subscription data). Upon receiving a successful response, the AMF 155 can subscribe to notifications using Nudm_SDM_Subscribe 920 when the requested data can be modified. The UDM 140 can subscribe to the UDR through Nudr_UDM_Subscribe. If the GPSI is available in the UE 100 subscription data, the GPSI can be provided to the AMF 155 in the subscription data from the UDM 140. In one example, the new AMF 155 can provide the UDM 140 the access type it serves for the UE 100 and the access type can be set to 3GPP access. The UDM 140 can store the associated access type in the UDR with the serving AMF 155 through Nudr_UDM_Update. After obtaining the mobile subscription data from the UDM 140, the new AMF 155 can create an MM context for the UE 100. In one example, when the UDM 140 stores the associated access type with the serving AMF 155, the UDM 140 can initiate Nudm_UECM_DeregistrationNotification 921 to the old AMF 155 corresponding to 3GPP access. The old AMF 155 can remove the MM context for the UE. If the serving NF removal reason indicated by the UDM 140 is initial registration, the old AMF 155 can invoke the Namf_EventExposure_Notify service operation for all associated SMF 160 for the UE 100 to notify the UE 100 deregistered from the old AMF 155.The SMF 160 can release the PDU session upon obtaining the notification. In one example, the old AMF 155 can unsubscribe from the subscription data using Nudm_SDM_unsubscribe 922 to the UDM 140.
[0195] In one example, if the AMF 155 decides to initiate PCF 135 communication, for example, the AMF 155 has not obtained the access and mobility policy for the UE 100, or if the access and mobility policy in the AMF 155 is no longer valid, the AMF 155 can select 925 the PCF 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, the AMF 155 can select the (V-)PCF identified by the PCF ID. If the PCF 135 identified by the PCF ID can not be used (e.g., no response from the PCF 135) or if no PCF ID is received from the old AMF 155, the AMF 155 can select 925 the PCF 135.
[0196] In one 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 inter-AMF 155 mobility, the new AMF 155 can include the PCF-ID in the Npcf AMPolicyControl Get operation. If the AMF 155 informs the PCF 135 of mobility restrictions (e.g., UE 100 location) to adjust, or if the PCF 135 updates the mobility restrictions itself due to certain conditions (e.g., applications in use, time and date), the PCF 135 can provide the updated mobility restrictions to the AMF 155.
[0197] In one example, the PCF 135 can invoke the Namf EventExposure Subscribe service operation 935 for UE 100 event subscription.
[0198] In one example, the AMF 155 can send an Nsmf_PDUSession_UpdateSMContext 936 to the SMF 160. In one example, the AMF 155 can invoke Nsmf_PDUSession_UpdateSMContext if the PDU sessions to be reactivated are included in the registration request. The AMF 155 can send an Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session to activate the user plane connection of the PDU session. The SMF 160 can decide to trigger intermediate UPF 110 insertion, removal, or change of e.g. PSA. In case of intermediate UPF 110 insertion, removal, or relocation for PDU sessions not included in the PDU sessions to be reactivated, this flow can be performed without N11 and N2 interaction to update the N3 user plane between the (R)AN 105 and 5GC. If any PDU session status indicates that it is released at the UE 100, the AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160. The AMF 155 can invoke the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160 in order to release any network resources related to the PDU session.
[0199] In one example, the new AMF 155 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 with the N3IWF to which the UE 100 is connected. In one example, the N3IWF can respond to the new AMF 155 with an N2 AMF 155 mobility response 940.
[0200] In one example, the new AMF 155 can send a registration accept 955 to the UE 100 (including: 5G-GUTI, registration area, mobility restrictions, PDU session status, allowed NSSAI, [mapping of allowed NSSAI], periodic registration update timer, LADN information, and accepted MICO mode, indication of IMS voice over PS session support, emergency service support indicator, etc.). In one example, the AMF 155 can send a registration accept message to the UE 100 indicating that the registration request has been accepted. If the AMF 155 allocates a new 5G-GUTI, it can include the 5G-GUTI. If the AMF 155 allocates a new registration area, it can send the registration area to the UE 100 via the registration accept message 955. If the registration area is not included in the registration accept message, the UE 100 can consider the old registration area valid. In one example, the mobility restrictions can be included in case the mobility restrictions can apply to the UE 100 and the registration type can not be an emergency registration. The AMF 155 can indicate to the UE 100 the established PDU sessions in the PDU session status. The UE 100 can locally remove any internal resources related to PDU sessions not marked as established in the received PDU session status. In one example, when the UE 100 is connected to two AMFs 155 belonging to different PLMNs via 3GPP access and non-3GPP access, the UE 100 can then locally remove any internal resources related to PDU sessions of the current PLMN not marked as established in the received PDU session status. If the PDU session status information is in the registration request, the AMF 155 can indicate the PDU session status to the UE. The mapping of allowed NSSAI can be the mapping of one or more S-NSSAIs of the allowed NSSAI to S-NSSAIs of the configured NSSAI of the HPLMN. The AMF 155 can include in the registration accept message 955 the LADN information of the LADNs available within the registration area determined by the AMF 155 for the UE. If the UE 100 included a MICO mode in the request, the AMF 155 can respond whether the MICO mode can be used. The AMF 155 can set the indication of IMS voice over PS session support. In one example, to set the indication of IMS voice over PS session support, the AMF 155 can perform a UE / RAN radio information and compatibility request procedure to check the compatibility of the UE 100 and RAN radio capabilities related to IMS voice over PS. In one example, the emergency service support indicator can inform the UE 100 that emergency services are supported, e.g., the UE 100 can request a PDU session for emergency services. In one example, the handover restriction list and the UE-AMBR can be provided by the AMF 155 to the NG-RAN.
[0201] In one example, the UE 100 can send a registration complete 960 message to the new AMF 155. In one example, the UE 100 can send a registration complete message 960 to the AMF 155 to confirm that a new 5G-GUTI can be allocated. In one example, the AMF 155 can release the signaling connection with the UE 100 when information about PDU sessions to be reactivated is not included in the registration request. In one example, the AMF 155 can not release the signaling connection after the registration procedure is completed when a subsequent request is included in the registration request. In one example, the AMF 155 can not release the signaling connection after the completion of the registration procedure if the AMF 155 is aware that there is some outstanding signaling in the AMF 155 or between the UE 100 and the 5GC.
[0202] As depicted in example Figure 10 and Figure 11 , the service request procedure, e.g., a service request procedure triggered by the UE 100, can be used by the UE 100 in CM-IDLE state to request establishment of a secure connection with the AMF 155. Figure 11 is a continuation of Figure 10 depicting the service request procedure. The service request procedure can be used to activate user plane connection for established PDU sessions. The service request procedure can be triggered by the UE 100 or the 5GC, and can be used when the UE 100 is in CM-IDLE and / or CM-CONNECTED, and can allow selective activation of user plane connection for some established PDU sessions.
[0203] In one example, the UE 100 in CM IDLE state can initiate the service request procedure to send uplink signaling messages, user data, etc., in response to a network paging request, etc. In one example, the AMF 155 can perform authentication after receiving the service request message. In one example, after establishing a signaling connection to the AMF 155, the UE 100 or the network can send signaling messages, e.g., PDU session establishment, from the UE 100 to the SMF 160 via the AMF 155.
[0204] In one example, for any service request, the AMF 155 can respond with a service accept message to synchronize the PDU session state between the UE 100 and the network. If the service request can not be accepted by the network, the AMF 155 can respond to the UE 100 with a service reject message. The service reject message can include an indication or a cause code that requests the UE 100 to perform a registration update procedure. In one example, for service requests due to user data, the network can take further actions if the user plane connection activation can not be successful. In Figure 10 and Figure 11 In an example, multiple UPFs can be involved, e.g., old UPF 110-2 and PDU Session Anchor, PSA, UPF 110-3.
[0205] In one example, UE 100 can send an AN message including AN parameters, mobility management, MM NAS service request 1005 (e.g., list of PDU sessions to activate, list of PDU sessions allowed, security parameters, PDU session status, etc.), etc., to (R)AN 105. In one example, UE 100 can provide a list of PDU sessions to activate when UE 100 can re-activate PDU sessions. The list of PDU sessions allowed can be provided by UE 100 when the service request can be a response to a paging or NAS notification, and can identify PDU sessions that can be transferred or associated to an access that can send the service request. In one example, for the case of NG-RAN, the AN parameters can include a selected PLMN ID and an establishment cause. The establishment cause can provide a reason for requesting establishment of an RRC connection. UE 100 can send the NAS service request message encapsulated in an RRC message to RAN 105 to AMF 155.
[0206] In one example, UE 100 can use the list of PDU sessions to activate to identify PDU sessions that will activate UP connections in the NAS service request message if the service request can be triggered for user data. UE 100 can not identify any PDU sessions if the service request can be triggered for signaling. If the procedure can be triggered for a paging response and / or UE 100 can have user data to transmit simultaneously, UE 100 can identify PDU sessions that can activate UP connections in the MM NAS service request message through the list of PDU sessions to activate.
[0207] In one example, if the service request through 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 PDU sessions allowed. In one example, the PDU session status can indicate PDU sessions available in UE 100. In one example, UE 100 can not trigger a service request procedure for a PDU session corresponding to a LADN when UE 100 can be outside an available area of the LADN. UE 100 can not identify such PDU sessions in the list of PDU sessions to activate if the service request can be triggered for other reasons.
[0208] In one example, the (R)AN 105 can send an N2 message 1010 (e.g., Service Request) including N2 parameters, MM NAS Service Request, etc. to the AMF 155. The AMF 155 can reject the N2 message if it can not handle the service request. In one example, the N2 parameters can include 5G-GUTI, selected PLMN ID, location information, RAT type, establishment cause, etc. if NG-RAN can be used. In one example, the 5G-GUTI can be obtained in the RRC procedure and the (R)AN 105 can select the AMF 155 according to the 5G-GUTI. In one example, the location information and RAT type can be related to the cell in which the UE 100 can camp. In one example, based on the PDU session status, the AMF 155 can initiate a PDU session release procedure in the network for the PDU session, the PDU session ID of which can be indicated by the UE 100 as not available.
[0209] In one example, the AMF 155 can initiate a NAS authentication / security procedure 1015 if the service request is not sent with integrity protection or integrity protection verification fails.
[0210] In one example, if the UE 100 triggers a service request to establish a signaling connection, the UE 100 and the network can exchange NAS signaling after the signaling connection is successfully established.
[0211] In one example, the AMF 155 can send a PDU Session Update Context Request 1020, e.g., Nsmf_PDUSession_UpdateSMContext request, to the SMF 160 including PDU session ID, cause, UE 100 location information, access type, etc.
[0212] In one example, the Nsmf_PDUSession_UpdateSMContext request can be invoked by the AMF 155 if the UE 100 can identify a PDU session to be activated in the NAS service request message. In one example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by the SMF 160 where the PDU session identified by the UE 100 can be related to another PDU session ID other than the PDU session ID that triggers the procedure. In one example, the Nsmf_PDUSession_UpdateSMContext request can be triggered by the SMF 160 where the current UE 100 location can be outside the validity area of the N2 information provided by the SMF 160 during the network triggered service request procedure. The AMF 155 can not send the N2 information provided by the SMF 160 during the network triggered service request procedure.
[0213] In one example, the AMF 155 can determine the PDU session to be activated and can send an Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session with the cause set to indicate user plane resources are established for the PDU session.
[0214] In one example, if the procedure can be triggered in response to a paging indicating non-3GPP access and the allowed PDU session list provided by the UE 100 can not include the PDU session for which the UE 100 is paged, the AMF 155 can inform the SMF 160 that the user plane for the PDU session can not be reactivated. The service request procedure can be successful without reactivating the user plane of any PDU session and the AMF 155 can inform the UE 100.
[0215] In one example, if the PDU session ID can correspond to a LADN and the SMF 160 can determine based on the UE 100 location report from the AMF 155 that the UE 100 can be outside the available area of the LADN, the SMF 160 can decide (based on local policy) to keep the PDU session, can reject the activation of the user plane connection of the PDU session, and can inform the AMF 155. In one example, if the procedure can be triggered by a service request triggered by the network, the SMF 160 can inform the UPF 110 initiating the data notification to discard downlink data for the PDU session and / or not provide further data notification messages. The SMF 160 can respond to the AMF 155 with an appropriate rejection cause and can stop the user plane activation of the PDU session.
[0216] In one example, if the PDU session ID can correspond to a LADN and the SMF 160 can determine based on the UE 100 location report from the AMF 155 that the UE 100 can be outside the available area of the LADN, 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 inform the AMF 155 that the PDU session can be released. The SMF 160 can respond to the AMF 155 with an appropriate rejection cause and can stop the user plane activation of the PDU session.
[0217] In one example, if UP activation of the PDU session can be accepted by the SMF 160, then based on the location information received from the AMF 155, the SMF 160 may check the UPF 110 selection 1025 criteria (e.g., slice isolation requirements, slice coexistence requirements, UPF 110 dynamic load, relative static capacity of UPF 110 between UPFs supporting the same DNN, UPF 110 locations available at the SMF 160, UE 100 location information, UPF 110 capabilities, and required functionality for a specific UE 100 session. In one example, an appropriate UPF 110 may be selected by matching the required functionality and features of the following: UE 100, DNN, PDU session type (i.e., 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 the UDM 140, DNAI included in the PCC rules, local operator policy, S-NSSAI, UE 100, the access technology used by the UPF 110, the logical topology of the UPF 110, etc.), and may decide to perform one or more of the following: continue to use the current UPF; if the UE 100 has moved out of the service area of the UPF 110 previously connected to the (R)AN 105 while keeping 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); re-establishment of the PDU session may be triggered to perform relocation / reallocation of the UPF 110 acting as the PDU session anchor, for example, the UE 100 has moved out of the service area of the anchor UPF 110 connected to the RAN 105.
[0218] In one example, SMF 160 may send an N4 session establishment request 1030 to UPF 110 (e.g., a new intermediate UPF 110). In one example, if SMF 160 may select a new UPF 110 as intermediate UPF 110-2 for a PDU session, or if SMF 160 may choose to insert an intermediate UPF 110 for a PDU session that may not have an intermediate UPF 110-2, the N4 session establishment request 1030 message may be sent to the new UPF 110, providing packet inspection, data forwarding, enforcement, and reporting rules installed on the new intermediate UPF. PDU session anchor addressing information (on N9) for the PDU session may be provided to intermediate UPF 110-2.
[0219] In one example, if a new UPF 110 is selected by the SMF 160 to replace the old (intermediate) UPF 110-2, the SMF 160 can include a data forwarding indication. The data forwarding indication can indicate to the UPF 110 that a second tunnel endpoint can be reserved for buffered DL data from the old I-UPF.
[0220] In one example, the new UPF 110 (intermediate) can send an N4 session establishment response message 1030 to the SMF 160. In case the UPF 110 can allocate CN tunnel information, the UPF 110 can provide the SMF 160 with DL CN tunnel information and UL CN tunnel information (e.g., CN N3 tunnel information) for the UPF 110 acting as a PDU session anchor point. If a data forwarding indication can be received, the new (intermediate) UPF 110 acting as a N3 termination point 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.
[0221] In one example, if the SMF 160 can select a new intermediate UPF 110 for a PDU session or can remove the old I-UPF 110-2, the SMF 160 can send an N4 session modification request message 1035 to the PDU session anchor point, PSA UPF 110-3, providing a data forwarding indication and DL tunnel information from the new intermediate UPF 110.
[0222] In one example, if a new intermediate UPF 110 can be added for a PDU session, the (PSA) UPF 110-3 can start sending DL data to the new I-UPF 110 as indicated in the DL tunnel information.
[0223] In one example, if a service request can be triggered by the network and the SMF 160 can remove the old I-UPF 110-2 and can not replace the old I-UPF 110-2 with a new I-UPF 110, the SMF 160 can include a data forwarding indication in the request. The data forwarding indication can indicate to 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 start buffering DL data that it can receive from the N6 interface at the same time.
[0224] In one example, the PSA UPF 110-3 (PSA) can send an N4 session modification response 1035 to the SMF 160. In one example, if a data forwarding indication can be received, the PSA UPF 110-3 can become an N3 termination point and can send the CN DL 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 (if any).
[0225] In one example, the SMF 160 can send an N4 session modification request 1045 to the old UPF 110-2 (e.g., can include a new UPF 110 address, a new UPF 110 DL tunnel ID, etc.). In one example, if a service request can be triggered by the network and / or the SMF 160 can remove the old (intermediate) UPF 110-2, the 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 the SMF 160 can allocate a new I-UPF 110, the DL tunnel information can be from the new (intermediate) UPF 110 that can act as an N3 termination point. If the SMF 160 can not allocate a new I-UPF 110, the DL tunnel information can be from the new UPF 110 (PSA) 110-3 that acts as an N3 termination point. The SMF 160 can start a timer to monitor the forwarding tunnel. In one example, the old (intermediate) UPF 110-2 can send an N4 session modification response message to the SMF 160.
[0226] In one example, if the I-UPF 110-2 can be relocated and a forwarding tunnel is established to a new I-UPF 110, the old (intermediate) UPF 110-2 can forward its buffered data to the new (intermediate) UPF 110 as an N3 termination point. In one example, if the old I-UPF 110-2 can be removed and a new I-UPF 110 can not be allocated to the PDU session and a forwarding tunnel can be established to the UPF 110 (PSA) 110-3, the old (intermediate) UPF 110-2 can forward its buffered data to the UPF 110 (PSA) 110-3 that acts as an N3 termination point.
[0227] In one example, upon receiving the Nsmf_PDUSession_UpdateSMContext request with a cause including, for example, establishment of user plane resources, the SMF 160 can send an N11 message 1060, for example, 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), cause) to the AMF 155. The 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, for PDU sessions that the SMF 160 can determine are served by the current UPF 110, for example, PDU session anchor or intermediate UPF, the SMF 160 can generate N2 SM information and can send the Nsmf_PDUSession_UpdateSMContext response 1060 155 to the AMF to establish the user plane. The N2 SM information can contain information that the AMF 155 can provide to the RAN 105. In one example, for PDU sessions that the SMF 160 can determine require UPF 110 relocation for the PDU session anchor UPF, the SMF 160 can reject the activation of the UP of the PDU session by sending the Nsmf_PDUSession_UpdateSMContext response to the UE 100 via the AMF 155 that can contain the N1 SM container. The N1 SM container can include the corresponding PDU session ID and PDU session re-establishment indication.
[0228] Upon receiving the Namf_EventExposure_Notify from the AMF 155 to the SMF 160 with an indication that the UE 100 is reachable, the SMF 160 can invoke the Namf_Communication_N1N2MessageTransfer service operation to the AMF 155 to establish the user plane of the PDU session if the SMF 160 can have pending DL data. In one example, the SMF 160 can resume sending DL data notification to the AMF 155 in case of DL data.
[0229] In one example, if the PDU session can correspond to a LADN and the UE 100 can be outside the available area of the LADN, or if the AMF 155 can inform the SMF 160 that the UE 100 can be reachable for regulatory priority service and the PDU session to be activated can not be for regulatory priority service; or if the SMF 160 can decide to perform PSA UPF 110-3 relocation for the requested PDU session, the SMF 160 can send a message to the AMF 155 to reject the activation of the UP of the PDU session by including a cause in the Nsmf_PDUSession_UpdateSMContext response.
[0230] In one example, the AMF 155 can send a N2 request message 1065 (e.g., N2 SM information received from the SMF 160, security context, AMF 155 signaling connection ID, handover restriction list, MM NAS service accept, recommended cell / TA / NG-RAN node identifier list) to the (R)AN 105. In one example, the RAN 105 can store the security context, AMF 155 signaling connection Id, QoS information for the QoS flows of the PDU session that can be activated, and N3 tunnel IDs in the UE 100 RAN 105 context. In one example, the MM NAS service accept can include the PDU session status in the AMF 155. If the UP activation of the PDU session can be rejected by the SMF 160, the MM NAS service accept can include the PDU session ID and the cause that the user plane resources can not be activated (e.g., LADN not available). The local PDU session release during the session request procedure can be indicated to the UE 100 via the session status.
[0231] In one example, if there are multiple PDU sessions that can involve multiple SMFs 160, the AMF 155 can not wait for responses from all SMFs 160 before it can send the N2 SM information to the UE 100. The AMF 155 can wait for all responses from the SMFs 160 before it can send the MM NAS service accept message to the UE 100.
[0232] In one example, if the procedure can be triggered for PDU session user plane activation, the AMF 155 can include at least one N2 SM information from the SMF 160. The AMF 155 can send additional N2 SM information from the SMF 160 in a separate N2 message (e.g., N2 Tunnel Setup Request) if any. Alternatively, if multiple SMFs 160 can be involved, the AMF 155 can send one N2 request message to the (R)AN 105 after all Nsmf_PDUSession_UpdateSMContext response service operations from all SMFs 160 associated with the UE 100 can be received. In this case, the N2 request message can include the N2 SM information received in one or more of the Nsmf_PDUSession_UpdateSMContext responses and PDU session IDs to enable the AMF 155 to associate the responses with the relevant SMF 160.
[0233] In one example, if the RAN 105 (e.g., NG RAN) node can provide a list of recommended cell / TA / NG-RAN node identifiers during the AN release procedure, the AMF 155 can include information from the list in the N2 request. The RAN 105 can use this information to allocate a RAN 105 notification area when the RAN 105 can decide to enable the RRC Inactive state for the UE 100.
[0234] If, for any of the PDU sessions established for the UE 100, the AMF 155 can receive an indication from the SMF 160 during the PDU session establishment procedure that the UE 100 can be using a PDU session related to a delay sensitive service, and the AMF 155 has received an indication from the UE 100 that the CM-CONNECTED can support the RRC Inactive state, the AMF 155 can include the UE’s RRC Inactive assistance information. In one example, the AMF 155 can include the UE’s RRC Inactive assistance information based on network configuration.
[0235] In one example, the (R)AN 105 can send a message to the UE 100 to perform an RRC connection reconfiguration 1070 with the UE 100 according to the QoS information and data radio bearers for all QoS flows of the PDU session for which the UP connection can be activated. In one example, user plane security can be established.
[0236] In one example, if the N2 request can include an MM NAS service accept message, the RAN 105 can forward the MM NAS service accept to the UE 100. The UE 100 can locally delete the context of the PDU session that can not be available in the 5GC.
[0237] In one example, if the N1 SM information can be transmitted to the UE 100 and can indicate that some PDU sessions can be re-established, the UE 100 can initiate PDU session re-establishment for the PDU sessions, which can re-establish the PDU sessions after the service request procedure is completed.
[0238] In one example, after the user plane radio resources can be set up, uplink data from the UE 100 can be forwarded to the RAN 105. The RAN 105 (e.g., NG-RAN) can send the uplink data to the UPF 110 address and the provided tunnel ID.
[0239] In one example, the (R)AN 105 can send the N2 Request Ack 1105 (e.g., N2 SM information (including: AN tunnel information, list of accepted QoS flows for PDU sessions for which UP connection is activated, list of rejected QoS flows for PDU sessions for which UP connection is activated)) to the AMF 155. In one example, the N2 request message can include N2 SM information, such as AN tunnel information. The RAN 105 can respond to the N2 SM information with a separate N2 message (e.g., N2 tunnel setup response). In one example, if multiple N2 SM information is included in the N2 request message, the N2 request acknowledgement can include multiple N2 SM information and information that enables the AMF 155 to associate the response with the related SMF 160.
[0240] In one example, the AMF 155 can send the PDU session based Nsmf_PDUSession_UpdateSMContext request 1110 (N2 SM information (AN tunnel information), RAT type) to the SMF 160. If the AMF 155 can receive N2 SM information(s) from the RAN 105, the AMF 155 can forward the N2 SM information to the related SMF 160. If the UE 100 time zone can change compared to the last reported UE 100 time zone, the AMF 155 can include the UE 100 time zone IE in the Nsmf_PDUSession_UpdateSMContext request message.
[0241] In one example, if dynamic PCC is deployed, the SMF 160 can initiate a notification about new location information to the PCF 135 (if subscribed) by invoking the Event Exposure Notify operation (e.g., Nsmf_EventExposure_Notify service operation). The PCF 135 can provide updated policy by invoking the Policy Control Update Notify message 1115 (e.g., Npcf_SMPolicyControl_UpdateNotify operation).
[0242] In one example, if the SMF 160 can select a new UPF 110 as an intermediate UPF 110 for the PDU session, the SMF 160 can initiate a N4 session modification procedure 1120 to the new I-UPF 110 and can provide AN tunnel information. Downlink data from the new I-UPF 110 can be forwarded to the RAN 105 and the UE 100. In one example, the UPF 110 can send a N4 session modification response 1120 to the SMF 160. In one example, the SMF 160 can send a Nsmf_PDUSession_UpdateSMContext response 1140 to the AMF 155.
[0243] In one example, if a forwarding tunnel to the new I-UPF 110 can be established and if a timer set for the forwarding tunnel can expire, the SMF 160 can send a N4 session modification request 1145 to the new (intermediate) UPF 110 acting as the N3 termination point to release the forwarding tunnel. In one example, the new (intermediate) UPF 110 can send a N4 session modification response 1145 to the SMF 160. In one example, the SMF 160 can send a N4 session modification request 1150 or a N4 session release request to the PSA UPF 110-3. In one example, if the SMF 160 can continue to use the old UPF 110-2, the SMF 160 can send a N4 session modification request 1155 providing AN tunnel information. In one example, if the SMF 160 can select a new UPF 110 as an intermediate UPF 110 and the old UPF 110-2 can not be the PSA UPF 110-3, the SMF 160 can initiate resource release after the timer expires by sending a N4 session release request (release cause) to the old intermediate UPF 110-2.
[0244] In one example, the old intermediate UPF 110-2 can send an N4 session modification response or N4 session release response 1155 to the SMF 160. The old UPF 110-2 can acknowledge the N4 session modification response or N4 session release response message to acknowledge the modification or release of resources. The AMF 155 can invoke the Namf_EventExposure_Notify service operation to notify the mobility related event to NFs that can have subscribed to the event after this procedure is completed. In one example, the AMF 155 can invoke the Namf_EventExposure_Notify to the SMF 160 if the SMF 160 has subscribed to the UE 100 moving into or out of an area of interest and if the current location of the UE can indicate that it can be moving into or out of the subscribed area of interest, or if the SMF 160 has subscribed to a LADN DNN and if the UE 100 can be moving into or out of an area where the LADN is available, or if the UE 100 can be in MICO mode and the AMF 155 has informed the SMF 160 that the UE 100 is unreachable and the SMF 160 can not send DL data notification to the AMF 155, and the AMF 155 can inform the SMF 160 that the UE 100 is reachable, or if the SMF 160 has subscribed to the UE 100 reachability status, the AMF 155 can inform the UE 100 reachability.
[0245] Figure 12 and Figure 13An example PDU session establishment procedure is depicted. In an example implementation, when a PDU session establishment procedure can be employed, the UE 100 can send a NAS message 1205 (or SM NAS message) including 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, Nl SM container (PDU session establishment request), etc. to the AMF 155. In one example, to establish a new PDU session, the UE 100 can generate a new PDU session ID. In one example, when emergency services can be required and an emergency PDU session can not have been established, the UE 100 can initiate a UE 100 requested PDU session establishment procedure with a request type indicating an emergency request. In one example, the UE 100 can initiate a UE 100 requested PDU session establishment procedure by transmitting a NAS message containing a PDU session establishment request within a Nl SM container. The PDU session establishment request can include a PDU type, SSC mode, protocol configuration options, etc. In one example, the request type can indicate an initial request if the PDU session establishment is a request to establish a new PDU session, an existing PDU session if the request relates to an existing PDU session between 3GPP access and non-3GPP access or an existing PDN connection in EPC. In one example, the request type can indicate an emergency request if the PDU session establishment can be a request to establish a PDU session for emergency services. The request type can indicate an existing emergency PDU session if the request relates to an existing PDU session for emergency services between 3GPP access and non-3GPP access. In one example, the NAS message sent by the UE 100 can be encapsulated by the AN in a N2 message to the AMF 155, which can include user location information and access technology type information. In one example, the PDU session establishment request message can contain an SM PDU DN request container containing information for external DN to PDU session authorization. In one example, if the procedure can be triggered for SSC mode 3 operation, the UE 100 can include an old PDU session ID in the NAS message that can indicate an ongoing PDU session to be released. The old PDU session ID can be an optional parameter, which can be included in this case. In one example, the AMF 155 can receive the NAS message (e.g., NAS SM message) from the AN along with user location information (e.g., cell ID in the case of RAN 105). In one example, the UE 100 can not trigger a PDU session establishment for a PDU session corresponding to a LADN when the UE 100 is outside the available area of the LADN.
[0246] In one example, the AMF 155 can determine that the NAS message or SM NAS message can correspond to a request for a new PDU session and that the PDU session ID can not be used for any existing PDU session of the UE 100 based on the request type indicating an initial request. If the NAS message does not contain an S-NSSAI, the AMF 155 can determine a default S-NSSAI for the requested PDU session according to the UE 100 subscription, if the NAS message can contain only one default S-NSSAI, based on operator policy. In one example, the AMF 155 can perform SMF 160 selection 1210 and select an SMF 160. If the request type can indicate an initial request or the request can be caused by a handover from EPS, the AMF 155 can store an association of the S-NSSAI, the PDU session ID, and the SMF 160 ID. In one example, if the request type is an initial request and if an old PDU session ID indicating an existing PDU session can be contained in the message, the AMF 155 can select an SMF 160 and can store an association of the new PDU session ID and the selected SMF 160 ID.
[0247] In one example, the AMF 155 can send an N11 message 1215, e.g., an Nsmf_PDUSession_CreateSMContext request (including: SUPI or PEI, DNN, S-NSSAI, PDU Session ID, AMF 155 ID, Request Type, N1 SM Container (PDU Session Establishment Request), User Location Information, Access Type, PEI, GPSI) or an Nsmf_PDUSession_UpdateSMContext request (SUPI, DNN, S-NSSAI, PDU Session ID, AMF 155 ID, Request Type, N1 SM Container (PDU Session Establishment Request), User Location Information, Access Type, RAT Type, PEI) to the SMF 160. In one example, if the AMF 155 can not have an association with the SMF 160 for the PDU Session ID provided by the UE 100 (e.g., when the Request Type indicates an initial request), the AMF 155 can invoke the Nsmf_PDUSession_CreateSMContext request, but if the AMF 155 is already associated with the SMF 160 for the PDU Session ID provided by the UE 100 (e.g., when the Request Type indicates an existing PDU Session), the AMF 155 can invoke the Nsmf_PDUSession_UpdateSMContext request. In one example, the AMF 155 ID can be the GUAMI that uniquely identifies the UE for the AMF 155 serving the UE 100. The AMF 155 can forward the PDU Session ID with the N1 SM Container containing the PDU Session Establishment Request received from the UE 100. When the UE 100 has registered for emergency services without providing a SUPI, the AMF 155 can provide a PEI instead of a SUPI. In the case that the UE 100 has registered for emergency services but has not yet been authenticated, the AMF 155 can indicate that the SUPI has not yet been authenticated.
[0248] In one example, if the request type indicates neither an emergency request nor an existing emergency PDU session, and if the SMF 160 is not already registered and subscription data can not be available, the SMF 160 can register with the UDM 140 and can retrieve subscription data 1225 and subscribe to be notified when subscription data can be modified. In one example, if the request type can indicate an existing PDU session or an existing emergency PDU session, the SMF 160 can determine that the request can be caused by a handover between 3GPP access and non-3GPP access or by a handover from EPS. The SMF 160 can identify the existing PDU session based on the PDU session ID. The SMF 160 can not create a new SM context but can update the existing SM context and can provide an indication of the updated SM context in the response to the AMF 155. If the request type can be an initial request and if an old PDU session ID can be included in the Nsmf_PDUSession_CreateSMContext request, the SMF 160 can identify the existing PDU session to be released based on the old PDU session ID.
[0249] In one example, the SMF 160 can send an N11 message response 1220, e.g., a PDU session create / update response, a Nsmf_PDUSession_CreateSMContext response 1220 (cause, SM context ID or N1 SM container (PDU session reject (cause))), or a Nsmf_PDUSession_UpdateSMContext response, to the AMF 155.
[0250] In one example, if the SMF 160 can perform a secondary authorization / authentication 1230 during the DN-AAA server establishes the PDU session, the SMF 160 can select a UPF 110 and can trigger PDU session establishment authentication / authorization.
[0251] In one example, if the request type can indicate an initial request, the SMF 160 can select an SSC mode for the PDU session. The SMF 160 can select one or more UPFs as needed. In case of PDU type IPv4 or IPv6, the SMF 160 can allocate an IP address / prefix for the PDU session. In case of PDU type IPv6, the SMF 160 can allocate an interface identifier to the UE 100 in order for the UE 100 to establish its link-local address. For unstructured PDU type, the SMF 160 can allocate an IPv6 prefix (based on UDP / IPv6) for the PDU session and N6 point-to-point tunnel.
[0252] In one example, if 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 the PCF 135 that has been selected for the PDU session. If dynamic PCC is not deployed, the SMF 160 can apply local policy.
[0253] In one example, the SMF 160 can perform a session management policy establishment procedure 1240 to establish a PDU session with the PCF 135 and can obtain default PCC rules for the PDU session. The GPSI can be included if available in the SMF 160. If the request type in 1215 indicates an existing PDU session, the SMF 160 can inform the PCF 135 of previously subscribed events through a session management policy modification procedure, and the PCF 135 can update policy information in the SMF 160. The PCF 135 can provide authorized Session-AMBR and authorized 5QI and ARP to the SMF 160. The PCF 135 can subscribe to IP allocation / release events (and can subscribe to other events) in the SMF 160.
[0254] In one example, the PCF 135 can set the ARP of the PCC rules to a value that can be reserved for emergency services based on the emergency DNN.
[0255] In one example, if the request type in 1215 indicates an initial request, the SMF 160 can select an SSC mode for the PDU session. The SMF 160 can select one or more UPFs 1245 as needed. In the case of a PDU type IPv4 or IPv6, the SMF 160 can allocate an IP address / prefix for the PDU session. In the case of a PDU type IPv6, the SMF 160 can allocate an interface identifier to the UE 100 so that the UE 100 establishes its link-local address. For an unstructured PDU type, the SMF 160 can allocate an IPv6 prefix for the PDU session and the N6 point-to-point tunnel (e.g., based on UDP / IPv6). In one example, for a PDU session of Ethernet PDU type, the SMF 160 can neither allocate a MAC address nor an IP address to the UE 100 for that PDU session.
[0256] In one example, if the request type in 1215 is an existing PDU session, the SMF 160 can maintain the same IP address / prefix that can be allocated to the UE 100 in the source network.
[0257] In one example, if the request type in 1215 indicates that the existing PDU session is moving between 3GPP access and non-3GPP access, the SMF 160 can maintain the SSC mode of the PDU session, e.g., the current PDU session anchor and IP address. In one example, the SMF 160 can trigger, e.g., a new intermediate UPF 110 insertion or allocation of a new UPF 110. In one example, if the request type indicates an emergency request, the SMF 160 can select 1245 a UPF 110 and can select SSC mode 1.
[0258] In one example, the SMF 160 can perform a session management policy modification 1250 procedure to report certain events to a previously subscribed PCF 135. If the request type is an initial request and dynamic PCC is deployed and the PDU type is IPv4 or IPv6, the SMF 160 can inform the (previously subscribed) PCF 135 with the allocated UE 100 IP address / prefix.
[0259] In one example, the PCF 135 can provide updated policies to the SMF 160. The PCF 135 can provide the authorized Session-AMBR and authorized 5QI and ARP to the SMF 160.
[0260] In one example, if the request type indicates an initial request, the SMF 160 can initiate a N4 session establishment procedure 1255 with the selected UPF 110. The SMF 160 can initiate a N4 session modification procedure with the selected UPF 110. In one example, the SMF 160 can send a N4 session establishment / modification request 1255 to the UPF 110 and can provide packet detection, enforcement, reporting rules, etc. to be installed on the UPF 110 for this PDU session. If CN tunnel information is allocated by the SMF 160, the CN tunnel information can be provided to the UPF 110. If the PDU session requires selective user plane deactivation, the SMF 160 can determine the inactivity timer and can provide it to the UPF 110. In one example, the UPF 110 can acknowledge by sending a N4 session establishment / modification response 1255. If CN tunnel information is allocated by the UPF, the CN tunnel information can be provided to the SMF 160. In one example, if multiple UPFs are selected for a PDU session, the SMF 160 can initiate a N4 session establishment / modification procedure 1255 using one or more UPFs 110 of the PDU session.
[0261] In one example, the SMF 160 can send a Namf_Communication_N1N2MessageTransfer 1305 message to the AMF 155 (including PDU Session ID, Access Type, N2 SM Information (PDU Session ID, QFI, QoS Profile, CN Tunnel Info, S-NSSAI, Session-AMBR, PDU Session Type, etc.), N1 SM Container (PDU Session Establishment Accept (QoS Rules, Selected SSC Mode, S-NSSAI, Allocated IPv4 Address, Interface Identifier, Session-AMBR, Selected PDU Session Type, etc.))). In case of multiple UPFs for a PDU Session, the CN Tunnel Info can include tunnel information related to the UPF 110 that terminates the N3. In one example, the N2 SM Information can carry information that the AMF 155 can forward to the (R)AN 105 (e.g., CN Tunnel Info corresponding to a core network address of the N3 tunnel corresponding to the PDU Session, one or more QoS Profiles and corresponding QFIs can be provided to the (R)AN 105, the PDU Session ID can be used by AN signaling with the UE 100 to indicate the association between the AN resources and the PDU Session of the UE 100, etc.). In one example, the PDU Session can be associated with an S-NSSAI and a DNN. In one example, the N1 SM Container can contain the PDU Session Establishment Accept that the AMF 155 can provide to the UE 100. In one example, multiple QoS Rules and QoS Profiles can be included in the PDU Session Establishment Accept within the N1 SM and the N2 SM Information. In one example, the Namf_Communication_N1N2MessageTransfer 1305 can also include the PDU Session ID and information that allows the AMF 155 to know which access to the UE 100 to use.
[0262] In one example, the AMF 155 can send a N2 PDU Session Request 1310 to the (R)AN 105 (including N2 SM Information, NAS Message (PDU Session ID, N1 SM Container (PDU Session Establishment Accept, etc.))). In one example, the AMF 155 can send a NAS Message 1310 to the (R)AN 105 that can include a PDU Session ID and a PDU Session Establishment Accept targeted to the UE 100 and the N2 SM Information received from the SMF 160 within the N2 PDU Session Request 1310.
[0263] In one example, the (R)AN 105 can initiate AN specific signaling exchange 1315 with the UE 100 that can be related to the information received from the SMF 160. In one example, in case of a 3GPP RAN 105, an RRC connection reconfiguration procedure can be conducted with the UE 100 to establish the necessary RAN 105 resources related to the QoS rules of the PDU Session Request 1310. In one example, the (R)AN 105 can allocate (R)AN 105 N3 tunnel information for the PDU Session. In case of dual connectivity, the master RAN 105 node can allocate some (zero or more) QFIs to be setup to the master RAN 105 node and others to the secondary RAN 105 node. The AN tunnel information can include one or more tunnel endpoints of the involved RAN 105 nodes and the QFIs allocated to one or more tunnel endpoints. The QFIs can be allocated to the master RAN 105 node or the secondary RAN 105 node. In one example, the (R)AN 105 can forward the NAS message 1310 (PDU Session ID, N1 SM Container (PDU Session Establishment Accept)) to the UE 100. If the necessary RAN 105 resources are established and the allocation of the (R)AN 105 tunnel information is successful, the (R)AN 105 can provide the NAS message to the UE 100.
[0264] In one example, the N2 PDU Session Response 1320 can include the PDU Session ID, cause, N2 SM information (PDU Session ID, AN tunnel information, list of accepted / rejected QFIs), etc. In one example, the AN tunnel information can correspond to the access network address of the N3 tunnel corresponding to the PDU Session.
[0265] In one example, the AMF 155 can forward the N2 SM information received from the (R)AN 105 to the SMF 160 via a 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, the SMF 160 can release the QoS profiles associated with the rejected QFIs.
[0266] In one example, the SMF 160 can initiate a N4 Session Modification procedure 1335 with the UPF 110. The SMF 160 can provide the AN tunnel information to the UPF 110 along with the corresponding forwarding rules. In one example, the UPF 110 can provide a N4 Session Modification Response 1335 to the SMF 160.
[0267] In one example, the SMF 160 can send an Nsmf_PDUSession_UpdateSMContext response 1340 (cause) to the AMF 155. In one example, after this step, the SMF 160 can subscribe to UE 100 mobility event notifications (e.g., location reporting, UE 100 moving in or out of an area of interest) from the AMF 155 by invoking the Namf_EventExposure_Subscribe service operation. For LADN, the SMF 160 can subscribe to UE 100 moving in or out of the LADN service area event notifications by providing the LADN DNN as an indicator of the area of interest. The AMF 155 can forward the relevant events subscribed by the SMF 160.
[0268] In one example, the SMF 160 can send an Nsmf_PDUSession_SMContextStatusNotify (release) 1345 to the AMF 155. In one example, the SMF 160 can notify the AMF 155 by invoking the Nsmf_PDUSession_SMContextStatusNotify (release) 1345 whenever the PDU session establishment is not successful during the procedure. The SMF 160 can release any N4 session created, any allocated PDU session address (e.g., IP address) and can release the association with the PCF 135.
[0269] In one example, in case of PDU type IPv6, the SMF 160 can generate an IPv6 router advertisement 1350 and can send it to the UE 100 via N4 and UPF 110.
[0270] In one example, the SMF 160 can unsubscribe 1360 from the modification of the session management subscription data for the corresponding (SUPI, DNN, S-NSSAI) using Nudm_SDM_Unsubscribe (SUPI, DNN, S-NSSAI) if the PDU session can not be established (if the SMF 160 is no longer handling the PDU session for the UE 100 for this (DNN, S-NSSAI)). In one example, the SMF 160 can deregister 1360 for a given PDU session using Nudm_UECM_Deregistration (SUPI, DNN, PDU session ID) if the PDU session can not be established.
[0271] A 5GS can operate as an independent Time-Sensitive Networking (TSN) network or as part of a non-independent TSN network, e.g., an industrial communication network, etc. The 5GS can support three modes of operation, as exemplified in Figure 15 The fully distributed model shown at the bottom, TSN end stations, e.g., talker and listener, can convey TSN flow requirements directly to the TSN network. Each TSN bridge on the path from talker to listener can propagate TSN user and network configuration information and active topology of TSN flows to neighboring bridges. Network resources can be managed locally in each TSN bridge. Figure 15 The centralized network and distributed user model shown in the middle, TSN end stations, e.g., talker and listener, can convey TSN flow requirements directly to the TSN network. TSN flow requirements are forwarded to a centralized network configuration (CNC). TSN bridges can provide their network capability information and active topology information to the CNC. The CNC can have a complete view of the TSN network and is able to compute respective end-to-end communication paths from talker to listener that satisfy the TSN flow requirements provided by the end stations. The CNC can provide the computation results as TSN configuration information to each TSN bridge in the path between the involved TSN end stations (talker to listener) as network configuration information. Figure 15 The centralized network and distributed user model shown in the middle, TSN end stations, e.g., talker and listener, can convey TSN flow requirements directly to the TSN network. TSN flow requirements are forwarded to a centralized network configuration (CNC). TSN bridges can provide their network capability information and active topology information to the CNC. The CNC can have a complete view of the TSN network and is able to compute respective end-to-end communication paths from talker to listener that satisfy the TSN flow requirements provided by the end stations. The CNC can provide the computation results as TSN configuration information to each TSN bridge in the path between the involved TSN end stations (talker to listener) as network configuration information. Figure 15 The fully centralized model shown at the top, TSN end stations, e.g., talker and listener, can convey TSN flow requirements to a centralized user configuration (CUC). The CUC can adjust the TSN end stations flow requirements before forwarding them to the CNC. The CNC performs the same operations as described in the centralized network / distributed user model, with the difference that the CNC can send specific TSN configuration information to the CUC. The CUC can determine / derive the TSN configuration information for the TSN end stations and notify them accordingly.
[0272] In one example, a TSN system can employ a 5GS as a TSN link, as a TSN bridge, etc. The TSN system can be integrated with the 5GS.
[0273] As an example Figure 17 As depicted, a 5GS can be used as a TSN link for external networks, e.g., as an Ethernet connection / link between a UE and a UPF. A link can be defined by the connected entities, i.e., two TSN bridges or a TSN end station and a TSN bridge, two TSN end stations, etc. Link capabilities can be described by the ingress / egress ports of the TSN bridges connected to the end of the link or by the TSN flow transmission requirements of the TSN end stations directly connected to the link. Open capabilities can include latency information, link speed, available bandwidth information, etc.
[0274] In Figure 18 and Figure 19In the depicted example, a 5GS can be employed as a TSN bridge. The 5GS can use the 5G QoS framework to receive TSN related reservation requests. The 5GS can employ 5G internal signaling to fulfill the TSN reservation requests. When the 5GS is deployed as a TSN bridge (e.g., a logical TSN bridge), the TSN bridge can include adaptation functions to transform 5GS protocols and information objects to TSN protocols and information objects, and vice versa. The 5GS bridge can provide TSN ingress and egress ports to the DN via a TSN translator (device) on the UE side and a “TSN translator” (CP and UP) on the CN side. The 5GS bridge can support different TSN configuration models. In one example, the TSN bridge can employ one or more TSN compliant interfaces with respective protocols for TSN end stations, TSN bridges, CNCs, CUCs, etc. on the control and / or user plane. The functions needed for the TSN bridge self-management and interaction with the CNC can be located at the network translator.
[0275] In one example, as Figure 20 depicted, a 5GS can be integrated with a TSN system. When the 5GS is integrated with the TSN system, various nodes of the 5GS (e.g., UPF, gNB, etc.) can interact with TSN procedures initiated by TSN endpoints and TSN controllers. This allows the 5GS and associated infrastructure to present itself as multiple TSN compliant endpoints.
[0276] As depicted in the example Figure 14 TSN system can generate control and data traffic and send to the 5GS. The control and data traffic can include TSN QoS information, stream information, port information, etc. Ethernet frames and / or headers can be mapped or encapsulated in 5G frames / data packets and sent to the 5GS via the air interface. A 5G radio with integrated Ethernet adapter can be connected to a wireless device (UE).
[0277] In example embodiments, a 3GPP network can support derivation of TSN bridge delay management object attributes, e.g., QoS flow packet delay budget (PDB) values, guaranteed flow bit rate (GFBR), maximum data burst volume (MDBV) indicated in QoS profiles, etc., of a 3GPP bridge based on 3GPP attributes (e.g., independentDelayMin / Max, dependentDelayMin / Max, etc.). Mapping of 3GPP attributes to TSN capabilities can be in the SMF and / or PCF, and exposure of capabilities to TSN bridges can be via NEF, SMF, PCF, etc.
[0278] In one example, the TSN bridge delay management object can include tuple (ingress port, egress port, traffic class) based attributes related to frame length. The attributes related to frame length can include: independentDelay Min / Max (e.g., the incurred bridge delay is independent of frame size (typically in ns)), dependentDelay Min / Max (e.g., the incurred bridge delay is based on base volume (typically in ps / byte)), etc.
[0279] In Figure 21 In the depicted example, when a centralized model or fully centralized model and centralized network / distributed user model is employed in the TSN network, the 5GS can be enhanced as a TSN bridge in the network. The AF can act as a controller function to collect 5GS virtual bridge related information and register it to the CNC via the TSN defined application interface, as the CNC maintains the capability and network topology of each TSN bridge in the TSN network. In one example, based on the information maintained by the CNC, the CNC can compute the forwarding and scheduling rules for the TSN flows required on each bridge for the CUC, which collects the TSN flow requirements from the end stations for the fully centralized model. In one example, QoS negotiation based on control plane can be employed. As Figure 21 As depicted, the CNC can negotiate with the PCF via the TSN AF to generate the TSN aware QoS profile for the flow. The TSN AF can convert the TSN traffic characteristics into TSN QoS requirements, TSN QoS profile, etc.
[0280] In one example, for a control plane based solution, the AF can act as a controller function to collect 5GS virtual bridge related information (e.g., the AF receives information from the SMF and can register it to the CNC via a TSN defined application interface). The information can include: bridge identification, port identification, bridge delay, transmission delay, bridge related topology information, etc. In one example, the bridge identification can identify a TSN bridge in a TSN network. In one example, the port identification can identify a port in a TSN bridge. The bridge delay can include a delay value of a frame when the frame passes through the bridge, which can include maximum and minimum values of independent and dependent delays. The transmission delay can be a delay of a frame transmitted from a TSN bridge port to an adjacent port on a different bridge. The topology related to the bridge can include bridge and TSN bridge and port identification and port capabilities of adjacent bridges. In one example, the identification of virtual bridges and related ports of a UPF can be pre-configured on the UPF and can be reported to the AF via the SMF when the UPF is set up. A UE or PDU session can be virtualized as a virtual port on a virtual bridge with an (unique) identification that can be assigned by the SMF or UPF. The TSN AF can interact with the 5G CN and can perform mapping between TSN network parameters and new deterministic QoS profiles for 5GS, negotiate traffic handling and related QoS policies, etc. In one example, the TSN AF can talk to other 5GC NFs directly or via the NEF.
[0281] In one example, the 5GS virtual bridge information can include bridge ID, port ID, bridge internal information (e.g., bridge delay), and bridge port related information (e.g., propagation delay), etc. The information of the 5GS virtual bridge can be reported to the AF by the 5GS control plane, such as bridge ID, port ID, bridge internal information (e.g., bridge delay), and bridge port related information (e.g., propagation delay), etc.
[0282] In one example, the 5GS virtual bridge information can include bridge ID, port ID, bridge internal information (e.g., bridge delay), and bridge port related information (e.g., propagation delay), etc. The information of the 5GS virtual bridge can be reported to the AF by the 5GS control plane, such as bridge ID, port ID, bridge internal information (e.g., bridge delay), and bridge port related information (e.g., propagation delay), etc. Figure 28In the depicted example, the 5GS virtual bridge can be UPF based, TSN network based (indicated by DNN), and the 5GS virtual bridge user plane can include UPF ports and UE ports connected to such UPF ports via PDU sessions. The identification of the virtual bridge and related UPF ports can be pre-configured on the UPF and can be reported to the AF by the SMF at UPF setup or PDU session establishment. The UE port identification can be unique in the 5GS virtual bridge and can be allocated by the UPF. The UPF port and UE port related information can be reported by the SMF to the AF directly or via NEF. The UPF port related information can be reported by the UPF to the SMF using node level signaling or PDU session level signaling. The UE port related information can be reported by the UE to the SMF through NAS or UP of its corresponding PDU session. In one example, the UE can operate in a switch mode, an Ethernet switch mode, etc. In one example, the UE port of the 5GS virtual bridge can be a physical port of the UE, a virtual port / interface of the UE, etc.
[0283] In one example, the traffic scheduling in the TSN bridge can be based on traffic classes, which are service levels for packet transmission. The TSN bridge port can support different traffic classes. In one example, if the TSN bridge is aware of VLANs, the TSN bridge port can support different VLANs. When the SMF selects a UPF for a PDU session, it can consider the traffic classes and VLANs subscribed by the UE.
[0284] As an example Figure 28 As depicted, UPF1 and UPF2 support different VLANs and traffic classes based on the deployment. When UE1 and UE2 establish PDU sessions, UPF1 and UPF2 are selected respectively to meet their subscribed VLANs and traffic classes. Since the bridge delay defined in 802.1QCC is based on traffic classes of port pairs, the UPF can determine the correct port pair to serve the PDU session, and the SMF can report the bridge delay on such port pair. Take UE1 in the figure as an example, UPF1 can determine Port1 supporting traffic class 2, VLAN 100 requested by UE1 to serve the PDU session. Then the SMF can report the bridge delay of traffic class 2 for the port pair (UE1 port and UPF1 port 1).
[0285] As an example Figure 29In the depicted example, for 5GS virtual bridge topology discovery, when a Link Layer Discovery Protocol (LLDP) packet is received from one or more devices (e.g., UE, terminal station, TSN device, Ethernet device, etc.), the UPF and UE can report the topology information to the SMF as defined in 802.1AB. Topology information can be reported when it is first discovered or when it is changed / modified. The UPF and UE can send LLDP packets to enable one or more devices to discover / report the 5GS virtual bridge. One or more ports of the 5GS virtual bridge can support sending or receiving LLDP. For propagation delay and port capabilities as defined in 802.1Qcc, the UPF and UE can report them to the SMF, similar to the topology information report. 5GS can support TSN network-specific QoS features and the mapping between such QoS features and traffic classes. The packet delay budget (PDB) in the QoS features can be used to achieve maximum delay transmission for deterministic delivery. The SMF can obtain the QoS features of the traffic class to which the UE subscribes, and the SMF can use the PDB therein as the bridge delay for the corresponding traffic class on the port pair. AF can collect / collect / obtain / receive and can maintain 5GS virtual bridge related information. AF can act as the control plane of the 5GS virtual bridge and can register or update this information to the CNC as defined by 802.1Qcc and 802.1AB. For QoS profile generation, AF can maintain the relationship between UE ID, 5GS virtual bridge ID and UE port ID. When receiving TSN flow rules (bridge ID, ingress port ID, egress port ID, flow description, flow id, etc.) from CNC, AF can determine / find the corresponding UE ID. AF can determine the traffic category in the TSN flow rule and map the traffic category to the corresponding 5QI.
[0286] In an example implementation, a TSN bridge can report capabilities. In one example, a 5GS virtual bridge and UPF port identities can be pre-configured based on deployment on UPF. A UPF can report its port capabilities and propagation delay to SMF as defined by 802.1Qcc, report topology information to SMF as defined by 802.1AB, and report corresponding DNN to SMF using node level signaling, and SMF can forward the received information to AF, either directly or via NEF, in order to generate or update 5GS virtual bridge and bridge port. A UE can send a PDU session establishment request to AMF. AMF can select a SMF for the PDU session. SMF can receive traffic classes and VLANs subscribed by UE from UDM, and can receive QoS characteristics (e.g., 5QI, PDB) corresponding to the subscribed traffic classes from PCF. SMF can select a UPF to support the subscribed traffic classes and the subscribed VLANs. SMF can send a N4 session establishment request to UPF with DNN, traffic class IDs, and VLAN values to request allocation of UE port IDs and determination of serving UPF ports. UPF can determine a 5GS virtual bridge for the PDU session, and can allocate identities for UE ports. Based on traffic classes and VLANs supported by UPF ports in the DN, UPF can determine that the UPF ports serve the PDU session. UPF can send the allocated UE port identities with corresponding 5GS virtual bridge identities, serving UPF port identities with corresponding traffic class IDs, etc. to SMF. SMF can send the related 5GS virtual bridge IDs for the PDU session, and can allocate UE port IDs for the UE. This information can be used by the UE to perform topology discovery and information reporting. SMF can use PDB in QoS characteristics as bridge delay for corresponding traffic class and port pairs, and can send 5GS virtual bridge related information (bridge delay, UE port IDs, UPF port IDs, traffic classes, 5GS virtual bridge IDs, UE IDs) to AF or via NEF in order to add UE ports or update bridge attributes.
[0287] In one example, when a PDU session is established, a UE can report its port capabilities and propagation delay to SMF through NAS or user plane as defined by 802.1Qcc and report topology information to SMF as defined by 802.1AB. An AF can receive / collect / gather and can maintain 5GS virtual bridge attributes, including bridge IDs, port IDs of UPF ports, port IDs of UE ports, port related capabilities, and bridge delays for port pairs, etc. The AF can send 5GS virtual bridge attributes to CNC to create a TSN bridge or update the bridge when bridge attributes change.
[0288] In an example embodiment, a UE can operate as an Ethernet switch. The SMF can configure the UE to operate as an Ethernet switch with configuration parameters provided during the configuration of the PDU session or TSN bridge. The PDU session can provide access to the end stations via the TSN bridge to communicate with one or more end stations. The UE operating as an Ethernet switch can be part of one or more TSN systems. One or more backend devices can be connected to the UE operating as an Ethernet switch. In one example, the SMF can provide configuration parameters to the UE in the switch mode. The configuration parameters can include an indicator of whether the UE in Ethernet switch mode can turn on or off the spanning tree algorithm, a periodic timer to send BDPUs messages, a bridge identification of the UE in Ethernet switch mode, an indicator of whether the UE in Ethernet switch mode can notify port state changes, an indicator of whether the UE in Ethernet switch mode can report a list of MAC addresses of connected TSN end stations, backend devices, etc. in the backend network.
[0289] For example, if the SMF indicates the UE to report a list of MAC addresses of backend devices or TSN end stations, the UE in the switch mode can obtain a list of MAC addresses of connected or changed backend devices in the backend network. In one example, when one PDU session provides communication for more than one TSN system, the UE can obtain / determine a mapping relationship of MAC addresses to TSN systems. The UE can notify the SMF of the list of MAC addresses and the mapping relationship in the PDU session establishment / modification procedure when the UE receives an indicator or detects a change of backend devices. The SMF can provide a set of Ethernet packet filters and forwarding rules to the UPF based on the list of MAC addresses and the mapping relationship. The UPF can detect and forward Ethernet frames based on the set of Ethernet packet filters and forwarding rules received from the SMF.
[0290] In one example, the UE in Ethernet switch mode can report its port states that can be generated due to performing the spanning tree algorithm, etc., so that the SMF can control the port states of the UPF based on the report to prevent waste of network resources.
[0291] In one example, the UPF can support S-tag (IEEE 802. lad), C-tag (IEEE 802. lq). In one example, the PDU session can provide access to one or more TSN systems, TSN end stations, etc. The S-tag and / or C-tag of the data packet flow can be employed. The TSN system configuration can be pre-configured on the UE or provided to the UE by the network, e.g., SMF, etc. In one example, a TSN system identifier can be employed to identify a TSN system, one or more TSN end stations, etc. In one example, the operator can allocate a list of TSN systems or TSN end station identifiers to the UE. The identifiers can be configured in the UDR, UDM, etc. The SMF can be configured by the operator with a mapping table for TSN identifiers, VLAN IDs, C-tags, S-tags, etc. The SMF can map the list of TSN end station identifiers connected to the UE notified through the PDU session establishment procedure into S-tags and C-tags and packet filters for uplink traffic. The UPF can insert the S-tags and C-tags into the traffic sent to N6, etc. based on the packet filters for uplink traffic.
[0292] In example embodiments, the UE can receive a SRP message from an end station. The UE can map the SRP message to 3GPP QoS parameters. The UE can initiate a PDU session establishment procedure to request a PDU session of a TSN system, a TSN end station supporting the QoS parameters derived from the SRP.
[0293] In one example, a 3GPP system, 5GS, etc. can be employed to act as a TSN bridge. The TSN system can transmit and receive data packets, data packet flows, etc. whose network resource requirements are determined by SRP messages, SRP announcements, speaker announcements, etc. Prior art requires the establishment of a PDU session prior to the SRP propagation between TSN end stations. Prior art does not provide a mechanism to transmit SRP messages prior to the establishment of a PDU session, which can result in excessive signaling and inefficient use of network resources. Embodiments of the present disclosure provide mechanisms to enhance the performance of TSN system, TSN bridge configuration, etc.
[0294] In an example embodiment, a first station (e.g., a TSN end station) can send an SRP message, a talker advertisement, a resource reservation request, etc. to a wireless device or UE. The TSN end station can send the SRP message to the UE via a TSN translator device, a TSN adapter device, etc. The TSN translator device or TSN adapter device can convert TSN protocols and information objects to 5GS protocols and information objects (and vice versa). The TSN translator device or TSN adapter device can employ a 3GPP radio with integrated Ethernet adapter. In one example, the UE can employ an integrated Ethernet adapter, a TSN translator, etc. In one example, the first station, TSN end station, etc. can be a 3GPP device / UE, a non-3GPP device / UE, a gateway, a residential gateway, an Ethernet switch, a virtual switch, a virtual UE supporting 3GPP and / or non-3GPP interfaces, etc. When the TSN end station is a 3GPP device, the interaction between the TSN end station and the UE can be via a PC5 interface, a PC3 interface, a device-to-device (D2D) interface, etc.
[0295] In one example, the SRP message (e.g., sent from a TSN end station to a UE) can include a stream ID, a data frame parameter, a traffic specification (TSpec), a priority and / or class, a cumulative delay, etc.
[0296] In one example, the stream ID can be an identifier that identifies a stream. The stream ID can be one or more (e.g., eight) octets that uniquely identify a stream. In one example, the stream ID can be subdivided into a 48-bit MAC address associated with a talker and a 16-bit unique ID used to distinguish different streams originating from the same talker. In an example, the stream ID can employ other encoding of one or more (e.g., eight) octets.
[0297] In one example, the data frame parameter can be addressing information for the stream that will be used to configure a filter table of a bridge for the reservation entry. The parameter can also include a destination MAC address, a VLAN identifier, etc. In one example, the destination MAC address can be a destination MAC address for the stream of data packets. In one example, the destination MAC address can be a multicast or locally administered address. In one example, the VLAN identifier can identify a VLAN for the stream of data packets.
[0298] A traffic specification (TSpec) for a stream can be used to configure traffic shaping mechanisms for the stream in a bridge on a port associated with the stream. The TSpec can also include a maximum frame size parameter (e.g., MaxFrameSize), a maximum interval frames parameter (e.g., MaxIntervalFrames), and / or the like. In one example, the maximum frame size parameter can include a value or parameter that indicates a maximum frame size that a talker (TSN end station) can generate as part of a stream. The maximum interval frames parameter can be a number of frames that a talker can generate per class measurement interval.
[0299] In one example, a priority and rank (e.g., PriorityAndRank) can include information about a priority class and an urgency status for a stream. The priority and rank can include a data frame priority, a rank value, and / or the like. The data frame priority can be used to generate a priority code point (PCP) tag for a data stream. The rank can be one or more bits to identify an urgent versus non-urgent stream (e.g., an urgent stream uses a value of 0 and a non-urgent can use a value of 1).
[0300] In one example, an accumulated latency can indicate a worst case latency that a stream can encounter from a talker to a listener. This value can change after a participant is registered. If the accumulated latency of an attribute sent to a participant has become different from its previously registered value, the participant can modify / change the attribute propagation from the talker announcement to the talker failure with a failure information code (e.g., indicating that the reported latency has changed). The talker can initialize this value with an estimate of the maximum expected latency between the egress of a packet from the talker’s network interface and the arrival of that packet at a network peer on the path to the listener. Each bridge on the path can add a maximum expected latency between the ingress of a packet on its own port and the next peer on the path of arrival.
[0301] In one example, when a UE receives a talker announcement, an SRP message, and / or the like from a TSN end station, a TSN translator, a TSN adapter device, and / or the like, the UE can determine to establish a PDU session for a stream to be transmitted by the TSN end station. In one example, based on an information element that identifies a request type, the UE can determine that an SRP request (e.g., an SRP message) is needed. The UE can determine to establish a PDU session (e.g., with an indication that the PDU session is for SRP / TSN, and / or the like), and can perform a PDU session establishment procedure. The UE can determine to modify a PDU session for SRP / TSN and can perform a PDU session modification procedure.
[0302] In one example, if the UE can determine that a PDU session establishment procedure is needed, the UE can send a NAS message to the AMF. The NAS message can include an SRP message, a PDU session type (e.g., Type = SRP / TSN) indicating that the request is for an SRP, an S-NSSAI, a DNN, a PDU session ID, a request type, an old PDU session ID, an N1 SM container (PDU session establishment request), and / or the like. In one example, the NAS message can include an identifier of a TSN system, an identifier of one or more bridges (TSN bridges, etc.), a port identifier of a UE of a TSN bridge, and / or the like. In one example, the DNN can identify a TSN system, a set or group of TSN bridges, and / or the like.
[0303] In example embodiments, the SRP message can include an identifier of a data packet flow (flow ID), at least one transport parameter for the data packet flow, and / or the like. The at least one transport parameter for the data packet flow can include a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a delay value, a traffic specification parameter, and / or the like. In one example, the data frame parameter can include a source MAC address of the data packet flow, a destination MAC address of the data packet flow, an identifier of a VLAN, and / or the like. In one example, the user-to-network requirement parameter can include a parameter indicating a delay requirement of the data packet flow, a parameter indicating a redundancy requirement of the data packet flow, and / or the like. In one example, the delay value can include a cumulative delay value, and / or the like. In one example, the traffic specification parameter can include a parameter indicating a data frame size, a parameter indicating a data frame quantity, and / or the like.
[0304] To establish a new PDU session, the UE can generate a new PDU session ID. The UE can initiate a UE-requested PDU session establishment procedure by transmitting a NAS message containing a PDU session establishment request within an N1 SM container. In one example, the N1-SM container can include an SRP message. In one example, the NAS message can include a container for an SRP message object. The PDU session establishment request can include an SRP message, a PDU session ID, a requested PDU session type (e.g., Type = SRP), a requested SSC mode, a 5GSM capability PCO, an SM PDU DN request container, a number of packet filters, an always-on PDU session request indication, and / or the like. The request type can indicate an initial request if the PDU session establishment is a request to establish a new PDU session, an existing PDU session if the request is a request for a PDU session handover between 3GPP access and non-3GPP access or from an existing PDN connection in EPC.
[0305] 5GSM core network capabilities can be provided by the UE and processed by the SMF. The 5GSM capabilities can include a UE integrity protection maximum data rate.
[0306] The number of data packet filters can indicate a number of packet filters supported by the signaling QoS rules for the PDU session being established. The number of packet filters indicated by the UE can be valid for the lifetime of the PDU session.
[0307] The NAS message sent by the UE can be encapsulated by the AN in a N2 message to the AMF. The NAS message can include user location information, access type information, and / or the like.
[0308] In one example, the UE can include an S-NSSAI from an allowed NSSAI of a current access type in the NAS message. The S-NSSAI can be an allowed NSSAI for a TSN system, one or more TSN bridges, and / or the like. If the UE is provided a mapping of allowed NSSAI, the UE can provide an S-NSSAI from the allowed NSSAI, a corresponding S-NSSAI from the mapping of allowed NSSAI, and / or the like.
[0309] In one example, the UE can establish a PDU session for an AS, an AF, a CUC, a CNC, and / or the like. If the UE is establishing a PDU session for an AS, an AF, a CUC, a CNC, and / or the like, and the UE is configured to discover a CUC or CNC address during connection establishment, the UE can include an indicator within a SM container that it requests an identifier of a CUC, a CNC, and / or the like.
[0310] In an example embodiment, the AMF can determine that the message corresponds to an SRP request, an SRP message, etc. The AMF can select an SMF. The AMF can select the SMF based on the SMF-ID received from the UDM. The AMF can select the SMF based on the PDU session type (e.g., SRP). The AMF can determine that the message corresponds to a request for a new PDU session based on the request type indicating an initial request, and determine that the PDU session ID is not used for any existing PDU session of the UE. If the NAS message does not contain an S-NSSAI, the AMF can determine the default S-NSSAI for the requested PDU session according to the UE subscription, if the NAS message contains only one default S-NSSAI, determine based on operator policy. In one example, the AMF can determine the (default) S-NSSAI based on an identifier of the TSN system, a TSN bridge (e.g., a bridge ID), etc. In one example, the AMF can determine a CUC and / or a CNC based on the S-NAASI, the UE subscription, the TSN system identifier, etc. when interaction with the CUC or CNC is needed. In one example, the AMF can select a locally configured CNC or CUC for a TSN bridge. When the NAS message contains an S-NSSAI but does not contain a DNN, if there is a default DNN in the subscription information of the UE, the AMF can determine the DNN for the requested PDU session by selecting the default DNN for the S-NSSAI; otherwise the AMF can select a locally configured DNN for the S-NSSAI. If the AMF cannot select an SMF (e.g., the network does not support the DNN provided by the UE, or the DNN provided by the UE is not in the list of subscribed DNNs for the S-NSSAI, and the list of subscribed DNNs does not contain a wildcard DNN), the AMF can reject the NAS message containing the PDU session establishment request from the UE with an appropriate reason.
[0311] In example embodiments, the AMF can send a session creation request to the SMF. In one example, the session creation request can include a Nsmf_PDUSession_CreateSMContext request, a Nsmf_PDUSession_UpdateSMContext request, and / or the like. The Nsmf_PDUSession_CreateSMContext request can include an SRP message, a PDU session type (e.g., type = SRP), an identifier of a TSN system, an identifier of a TSN bridge, a bridge ID, a port ID, a SUPI, a DNN, an S-NSSAI, a PDU session ID, an AMF ID, a request type, a PCF ID, a priority access, an N1 SM container (PDU session establishment request), user location information, an access type, a PEI, a GPSI, UE presence in LADN service area, subscription PDU session status notification, DNN selection mode, trace requirement, and / or the like. In one example, the Nsmf_PDUSession_UpdateSMContext request can include an SRP message, a PDU session type (e.g., type = SRP), an identifier of a TSN system, an identifier of a TSN bridge, a bridge ID, a port ID, a SUPI, a DNN, an S-NSSAI, a PDU session ID, an AMF ID, a request type, an N1 SM container (PDU session establishment request), user location information, an access type, a RAT type, a PEI, and / or the like.
[0312] In one example, the AMF ID can be a GUAMI of the UE, which identifies the AMF serving the UE. The AMF can forward the PDU session ID with the N1 SM container containing the PDU session establishment request received from the UE. The GPSI can be included if it is available at the AMF. The AMF can determine the access type and the RAT type based on the global RAN node ID associated with the N2 interface.
[0313] In one example, the AMF can provide the PEI without providing the SUPI when the UE is in a restricted service state and has registered for emergency services (i.e., emergency registration).
[0314] In one example, the SMF can receive a setup cause from the AMF. The setup cause can indicate that the PDU session can be used for SRP, SRP message, SRP procedure, TSN system resource reservation, etc. The AMF can include a message priority header to indicate priority information when the setup cause received by the SMF from the AMF as part of the AN parameters in the registration procedure or service request procedure is associated with a priority service (e.g., TSN, SRP, MPS, MCS). The SMF can use the message priority header to determine whether the UE request is exempted from NAS level congestion control. Other NFs relay the priority information by including the message priority header in service-based interfaces. The AMF can include an identifier of the PCF (e.g., PCF ID) in the Nsmf_PDUSession_CreateSMContext request. The PCF ID can identify the H-PCF in non-roaming cases and the V-PCF in local breakout roaming cases.
[0315] In one example, the SMF can receive an SRP message from the AMF. The SMF can receive the SRP message via the N11 interface, etc. The AMF can employ service-based interaction messaging (e.g., Nsmf_PDUSession_CreateSMContext, etc.) with the SMF via the N11 interface. In one example, the SMF can extract the SRP message from the Nsmf_PDUSession_CreateSMContext message. The SMF can extract / derive / decapsulate information of the flows from the SRP message and provide it as a QoS flow request to the PCF. In one example, the SMF can map the SRP message to a QoS flow request. The SMF can select a PCF or can employ a locally configured PCF to obtain PCC rules for the PDU session. The SMF can perform a session management (SM) policy association establishment procedure. The policy association procedure can be used to establish SM policy association with the PCF and obtain (default) PCC rules for the PDU session. The policy association procedure can employ the GPSI. In one example, if the SM policy association is for an existing PDU session, the SMF can provide information about the policy control request trigger conditions that are satisfied by the SM policy association modification procedure that has been initiated by the SMF. In one example, the PCF can send policy information to the SMF.
[0316] In one example, the SMF can select a user plane function (UPF). The SMF can select the UP based on the SRP capability, one or more elements of the SRP message, TSN capability support, etc. The SMF can query a network repository function (NRF) to select the UPF. The SMF can employ the Nnrf_NFDiscovery service, the Nnrf_NFDiscovery_Request service operation, etc. of the NRF. The SMF can send a discovery request message (e.g., a Nnrf_NFDiscovery_Request message, a Nnrf_discovery_request message, etc.) to the NRF including a NF type (e.g., UPF), SRP capability, one or more elements of the SRP message, TSN capability support, etc. indicating a request to select / discover the UPF for TSN (system). The NRF can send a query response (e.g., a Nnrf_NFdiscovery_response, etc.) message including an identifier of the UPF, an address of the UPF, etc.
[0317] In one example, the SMF can send a session establishment request (e.g., a N4 session establishment request, etc.) to the UPF. The N4 session establishment request can include packet detection rules for QoS flows, a bridge id (e.g., an identifier of a TSN bridge, etc.), a port id (e.g., associated with a TSN system, a data packet flow, a SRP, etc.), an identifier of the N4 session (N4 session ID), a PDU session type (e.g., TSN, SRP, Ethernet, IPv4, IPv6, unstructured, etc.), an identifier of the session (e.g., PDU session), etc. In one example, a TSN bridge can include a pair / tuple of one or more UEs and one or more UPFs.
[0318] The SMF can send a N4 session establishment / modification request to the UPF and can provide packet detection, enforcement, and reporting rules to be installed on the UPF for the PDU session. If CN tunnel information is allocated by the SMF, the CN tunnel information can be provided to the UPF. If the PDU session requires selective user plane deactivation, the SMF can determine an inactivity timer and provide it to the UPF. In one example, the value of the inactivity timer can be determined based on the SRP message and TSN system requirements. The UPF can acknowledge by sending a N4 session establishment / modification response to the SMF. If CN tunnel information is allocated by the UPF, the CN tunnel information can be provided to the SMF.
[0319] In one example, the SMF can send / forward the SRP message to the UPF. In response to receiving the SRP message, the SMF can send the SRP message to the second TSN bridge. The SMF can send the SRP message to the second TSN bridge via an egress port of the TSN system. The second TSN bridge can receive the SRP via a port at the UE, a port at the UPF, and / or the like. In one example, the UPF can send the SRP message to a second station (e.g., a TSN end station, a TSN device, a non-3GPP device, a 3GPP device, and / or the like). In one example, in response to receiving the SRP message, the second station can send an SRP response message (e.g., an SRP message response, a listener ready message / advertisement, and / or the like). The SRP response message can be a listener ready message and / or the like indicating that the second station of the TSN system is ready to receive / send / transmit TSN data packets, a stream of data packets, and / or the like. In one example, the second station can send the SRP response message via the second TSN bridge (e.g., via one or more TSN bridges).
[0320] In one example, the second station can send the SRP message response (SRP response message) to the UPF. The UPF can send / forward the SRP response message to the SMF via the N4 session identified by the N4 session ID. For the PDU session of the TSN system, the UPF can send the SRP response message via the session established between the SMF and the UPF. The session between the SMF and the UPF can be an N4 session. The UPF can send the SRP response message via the N4 session, an N4 message, an N4 reporting procedure, and / or the like, including the N4 session ID, the port ID, the TSN bridge ID, the SRP response message, an identifier of the second station, an identifier of the first station, and / or the like.
[0321] In one example, the second station can be an AF, AS, or the like. In one example, the AF, AS, or the like can send an SRP response message in response to receiving the SRP message. The AS / AF can receive the SRP message via a NEF, PCF, SMF, UPF, or the like. The second station can receive the SRP message via a control plane or user plane, via a PDU session, signaling, or the like. In one example, the SRP response message can be sent by the second station after a successful establishment of a PDU session for a TSN system or SRP. In one example, the SMF can send the SRP message to a second TSN bridge or one or more TSN bridges if the SRP request is successful (e.g., the PDU session establishment for TSN is successful). In example implementations, the second station (e.g., one or more listeners, or the like) can request the network to reserve resources for sending and / or receiving a data packet stream for a TSN system. In one example, the SRP message can trigger a service request procedure or a network initiated PDU session establishment, a network initiated PDU session modification for one or more listeners. In one example, if the second station (listener) fails to request (e.g., based on the SRP message, or the like) the network to reserve resources, the second station can send a listener failure message to the talker (e.g., the first station). In one example, the SRP can be propagated / transmitted through one or more TSN bridges. An error, a failure to reserve resources based on the SRP message, insufficient resources to support the SRP reservation, or the like can result in a talker ready failure, a talker failure, and / or a similar message. In one example, a talker failure message can be sent / propagated to the end station if there are insufficient resources from the listener to the talker path to support the SRP request for the data packet stream.
[0322] In one example, the SMF can send the SRP message to an application function (AF), AS, or the like. The SMF can send the SRP message to a UPF via a N4 interface. The UPF can send the SRP message to the AF / AS. The SMF can send the SRP message to the AF, AS, or the like via a NEF. The SMF can send the SRP message to the NEF using a Nnef service operation procedure (e.g., a message delivery request including an AF ID, an AS ID, or the like). The SMF can select the NEF based on local information or via a NRF, a UDM, a UDR, or the like.
[0323] In one example, the SMF can send the SRP message to a PCF via a N7 interface. The SMF can employ a service-based interaction of the PCF, e.g., a Npcf service operation, or the like. The SMF can send a message to the PCF including the SRP message, a SUPI, a bridge ID, or the like. The SMF can send the SRP message to the PCF. The PCF can determine an AF, an AS, or a centralized controller (e.g., a CNC, a CUC, or the like) and send the SRP message to the AF, the AS, the centralized controller, or the like.
[0324] In one example, the SMF can send a Namf_Communication_N1N2MessageTransfer message to the AMF, which includes a PDU Session ID, N2 SM information (PDU Session ID, QFI, QoS profiles, CN tunnel information, S-NSSAI from allowed NSSAI, Session-AMBR, PDU session type, user plane security enforcement information, UE integrity protection maximum data rate), N1 SM container (PDU session establishment accept (QoS rules and QoS flow level QoS parameters (if needed for QoS flows associated with QoS rules), selected SSC mode, S-NSSAI, DNN, allocated IPv4 address, interface identifier, Session-AMBR, selected PDU session type, reflective QoS timer (if available), P-CSCF address, [always-on PDU session]), etc. The N2 SM information can include information that the AMF can forward to the (R)AN node. The N2 SM information can include CN tunnel information that corresponds to a core network address of an N3 tunnel corresponding to the PDU session, one or more QoS profiles and corresponding QFI that can be provided to the (R)AN, PDU session ID that can be used by AN signaling with the UE to indicate an association between (R)AN resources and the PDU session of the UE, PDU session associated with S-NSSAI and DNN, user plane security enforcement information. The N1 SM container can include a PDU session establishment accept that the AMF can provide to the UE. If the UE requested P-CSCF discovery, the message can include a P-CSCF IP address determined by the SMF. The PDU session establishment accept can include S-NSSAI from allowed NSSAI.
[0325] In one example, the PDU session establishment accept in the N1 SM and in the N2 SM information can include one or more QoS rules, QoS flow level QoS parameters for QoS flows associated with those QoS rules, and QoS profiles. The Namf_Communication_N1N2MessageTransfer can include a PDU session ID, allowing the AMF to know which access to the UE to use.
[0326] In one example, the AMF can send a N2 PDU Session Request to a base station (e.g., RAN, NG RAN, etc.). The N2 PDU Session Request can include N2 SM information, NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept)), etc. The AMF can send the NAS message including the PDU Session ID targeting the UE and the PDU Session Establishment Accept along with the N2 SM information received from the SMF within the N2 PDU Session Request to the (R)AN. In one example, the base station (e.g., (R)AN) can send / issue AN specific signaling to the UE. The (R)AN can issue AN specific signaling exchange with the UE that can be related to the information received from the SMF. For example, in the case of NG-RAN, an RRC Connection Reconfiguration can occur where the UE establishes the necessary NG-RAN resources related to the QoS rules of the PDU Session Request. The (R)AN can allocate (R)AN N3 tunnel information for the PDU Session. In one example, in the case of dual connectivity, the master RAN node can allocate some (zero or more) QFIs to be set to the master RAN node and other QFIs to the secondary RAN node. The AN tunnel information can include tunnel endpoints for one or more involved (R)AN nodes and QFIs allocated to one or more tunnel endpoints. The QFIs can be allocated to the master RAN node or the secondary RAN node. In one example, the (R)AN can forward the NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept)) to the UE. If the necessary (R)AN resources are established and the allocation of the (R)AN tunnel information is successful, the (R)AN can provide the NAS message to the UE. In one example, the (R)AN can send a N2 PDU Session Response message to the AMF (e.g., including PDU Session ID, cause, N2 SM information (PDU Session ID, AN tunnel information, list of accepted / rejected QFIs, user plane enforcement policy notification, etc.), etc.). The AN tunnel information can correspond to access network addresses of N3 tunnels corresponding to the PDU Session. In one example, if the base station (e.g., NG-RAN, (R)AN, etc.) rejects a QFI, the SMF can update the QoS rules and QoS flow level QoS parameters accordingly if needed by the QoS flows associated with the QoS rules in the UE. The NG-RAN can reject the establishment of UP resources for a PDU Session when it cannot meet the user plane security enforcement information with the required values. In this case, the SMF can release the PDU Session. The NG-RAN can notify the SMF when it cannot complete the user plane security enforcement using the preferred values.
[0327] In one example, the AMF can send an Nsmf_PDUSession_UpdateSMContext request (e.g., including N2 SM information, request type, etc.) to the SMF. The AMF can forward the N2 SM information received from the (R)AN to the SMF. If a list of rejected QFIs is included in the N2 SM information, the SMF can release the QoS profiles associated with the rejected QFIs. If a user plane enforcement policy notification in the N2 SM information indicates that user plane resources cannot be established and the user plane enforcement policy indicates a requirement (e.g., using a “required” field, etc.), the SMF can release the PDU session. The SMF can initiate a N4 session modification procedure with the UPF. The SMF can provide the AN tunnel information, corresponding forwarding rules, etc. to the UPF. The UPF can provide a N4 session modification response to the SMF. In one example, the SMF can send an Nsmf_PDUSession_UpdateSMContext response (e.g., including a cause value, etc.) to the AMF. In one example, the SMF can send a release message, e.g., Nsmf_PDUSession_SMContextStatusNotify (release), etc., to the AMF. If the PDU session establishment is not successful during the procedure, the SMF can inform the AMF by invoking Nsmf_PDUSession_SMContextStatusNotify (release). The SMF can release any N4 session created, any allocated PDU session address (e.g., IP address) and release the association with the PCF.
[0328] In one example, the SMF can forward / send a SRP response message to the UE. The SMF can send the SRP message via a non-access stratum message (e.g., SM-NAS, NAS-SM, etc.). The SMF can employ an N11 interface between the SMF and the AMF to transport the SRP response message. The SMF can employ a Namf_Communication_N1N2MessageTransfer message, etc., to send the SRP response message. The Namf_Communication_N1N2MessageTransfer message can include the SRP response message, an identifier of the first station, etc.
[0329] In one example, a UE (e.g., wireless device, etc.) can receive a SRP response message from the SMF via a NAS message as depicted in Figure 22 and Figure 24 In one example, a UE (e.g., wireless device, etc.) can receive a SRP response message from the SMF via a NAS message as depicted in Figure 23 and Figure 25As depicted, the UE can receive the SRP response message via a PDU session, a UPF, a user plane, etc. In one example, in response to receiving the SRP response, the UE can determine that the SRP response message is for the talker (first station of the TSN). The UE can extract the received message, which can include the SRP response message, a terminal station identifier, a TSN bridge id, a port id, etc., and send the SRP response message to the first terminal station via the port. The UE can send the SRP response message to the talker via a TSN translator, an Ethernet adapter, an N60 interface, etc. The talker (first terminal station) can transmit a data packet stream to one or more listeners, e.g., via a PDU session.
[0330] In some embodiments, the UE can receive a SRP response message from a talker (first station of the TSN) via a PDU session, a UPF, a user plane, etc. In one example, in response to receiving the SRP response, the UE can determine that the SRP response message is for the listener (second station of the TSN). The UE can extract the received message, which can include the SRP response message, a terminal station identifier, a TSN bridge id, a port id, etc., and send the SRP response message to the second terminal station via the port. The UE can send the SRP response message to the listener via a TSN translator, an Ethernet adapter, an N60 interface, etc. The listener (second terminal station) can receive the data packet stream from the talker (first terminal station). Figure 27In the depicted example implementation, a first TSN bridge can send an SRP message to a TSN end station via a second TSN bridge. A TSN bridge (e.g., the first TSN bridge) can send an SRP message to a CNC, CUC, etc. The CNC can determine a TSN bridge based on elements of the SRP message, an identifier of the TSN end station, etc. The CNC can send the SRP message to a second TSN bridge (e.g., including a 3GPP system, a 5G system, etc.). In one example, a PCF, SMF, NEF, etc. of a 5GS can send a trigger to a UE connected / associated with a (TSN) end station. The association can be determined based on a bridge id, a port id, a UE id, a UPF id, a port of a UPF / UE associated with a TSN system or TSN end station, etc. In one example, a CNC can receive an SRP message and can forward the SRP message to an AF. The AF can send the SRP to a NEF. The NEF can send the SRP message to a PCF or SMF. In one example, an AF / AS can receive an SRP message from a first TSN bridge. The AF / AS can send the SRP message to a PCF or SMF. The AF / AS can send the SRP message to a PCF or SMF via a NEF. In one example, a SMF, PCF, NEF, etc. can trigger a PDU session establishment / modification, indicating that the PDU session establishment / modification can be for a TSN system, SRP propagation, etc. In one example, a PCF, SMF, NEF, etc. can map an SRP message to one or more QoS flow parameters. In one example, a PCF can trigger a policy delivery procedure to a UE (e.g., URSP), thereby triggering a PDU session establishment. The URSP can include an S-NSSAI, a DNN, an association of a PDU session ID to a TSN system, one or more QoS flow requirements, etc. The UE can establish a PDU session based on the URSP by performing a PDU session establishment request or a PDU session modification request. The UE can send a NAS message to a SMF (e.g., via an AMF). The NAS message can include an SRP message, a PDU session type indicating that the request is for SRP / TSN (e.g., type = SRP / TSN), an S-NSSAI, a DNN, a PDU session ID, a request type, an old PDU session ID, an N1 SM container (PDU session establishment request), etc. In one example, the NAS message can include an identifier of a TSN system, an identifier of one or more bridges (TSN bridges, etc.), a port identifier of a UE of a TSN bridge, etc. In one example, a DNN can identify a TSN system, a set or group of TSN bridges, etc.
[0331] In one example, the PCF can perform a PCF initiated SM policy association modification procedure to inform the SMF about the modification of the policy. This can be triggered by a policy decision or an AF request, for example, impact of application function on traffic routing, etc. The UDM can update the subscription data of the SMF by Nudm_SDM_Notification (e.g., including SUPI, session management subscription data, etc.). The SMF can update the session management subscription data and can acknowledge the UDM by returning an acknowledgement with (e.g., SUPI, etc.). In one example, the SMF can request modification. The SMF can modify the PDU session. The procedure can be triggered based on locally configured policy or triggered from (R)AN. This procedure can be triggered if UP connection is activated and the SMF has marked the status of one or more QoS flows to be deleted in 5GC but not synchronized with the UE.
[0332] In one example, the SMF can invoke Namf_Communication_N1N2MessageTransfer. The Namf_Communication_N1N2MessageTransfer can include the SRP message, an indication that the request is for TSN / SRP, a PDU session type indicating a TSN / SRP type PDU session, N2 SM information (PDU session ID, QFI, QoS profile, Session-AMBR), an N1 SM container (PDU session modification command (PDU session ID, QoS rules, QoS flow level QoS parameters (if needed for the QoS flow associated with the QoS rule), QoS rule operation and QoS flow level QoS parameter operation, Session-AMBR)), etc.
[0333] In one example, if the UE is in CM-IDLE state and ATC is activated, the AMF can update and store the UE context based on Namf_Communication_N1N2MessageTransfer. When the UE is reachable, e.g., when the UE enters CM-CONNECTED state, the AMF can forward the N1 message to synchronize the UE context with the UE. The AMF can send a N2 PDU Session Request (e.g., including N2 SM information received from the SMF, NAS message (SRP message, PDU Session Type = TSN / SRP, PDU Session ID, N1 SM container (PDU Session Modification Command), etc.), etc.) message to the (R)AN. The (R)AN can initiate AN specific signaling exchange with the UE related to the information received from the SMF. For example, in the case of NG-RAN, an RRC Connection Reconfiguration can occur where the UE modifies the necessary (R)AN resources related to the PDU Session. The (R)AN can confirm the N2 PDU Session Request by sending a N2 PDU Session Ack (N2 SM information (list of accepted / rejected QFIs, AN tunnel information, PDU Session ID, assistance RAT usage data), user location information) message to the AMF. In the case of dual connectivity, if one or more QFIs are added to the PDU Session, the master RAN node can allocate one or more of these QFIs to a NG-RAN node that was not previously involved in the PDU Session. In this case, the AN tunnel information includes new N3 tunnel endpoints allocated to the QFIs for the new NG-RAN node. Correspondingly, if one or more QFIs are removed from the PDU Session, the (R)AN node can no longer participate in the PDU Session and the corresponding tunnel endpoints can be removed from the AN tunnel information. If the NG-RAN is unable to fulfill the user plane security enforcement information for the corresponding QoS profile, e.g., due to exceeding the UE integrity protection maximum data rate, the NG-RAN can reject the QFI.
[0334] The AMF can forward / send the N2 SM information and user location information received from the AN to the SMF via the Nsmf_PDUSession_UpdateSMContext service operation. The SMF can reply with a Nsmf_PDUSession_UpdateSMContext response. The N2 SM information can include the assistance RAT usage data. If the (R)AN rejected a QFI, the SMF is responsible for updating the QoS rules and QoS flow level QoS parameters accordingly if needed for the QoS flows associated with the QoS rules in the UE. The SMF can update the N4 session of the UPF involved in the PDU session modification by sending a N4 session modification request message to the UPF based on the QoS flows derived from the SRP message. If a new QoS flow is to be created, the SMF can update the UPF with the UL data packet detection rules of the new QoS flow derived / mapped from the SRP message.
[0335] The UE can acknowledge the PDU session modification command by sending a NAS message. The NAS message can include the SRP message, PDU session type, port id, bridge id, PDU session ID, N1 SM container (PDU session modification command acknowledgement, etc.) message, etc. In one example, the N1 SM container can include the SRP message. The (R)AN can forward the NAS message to the AMF. The AMF can send / forward the N1 SM container (SRP message, PDU session modification command acknowledgement) and user location information, etc. received from the AN to the SMF via the Nsmf_PDUSession_UpdateSMContext service operation. The SMF can reply with a Nsmf_PDUSession_UpdateSMContext response.
[0336] In one example, the SMF can update the N4 session of the UPF involved in the PDU session modification by sending a N4 session modification request (N4 session ID) message to the UPF. For PDU sessions of Ethernet PDU session type, the SMF can inform the UPF to add or remove the set of Ethernet packet filters and forwarding rules.
[0337] In one example, if the SMF interacts with the PCF, the SMF can inform the PCF whether it can enforce the PCC decision by performing the SMF initiated SM policy association modification procedure.
[0338] In one example, as Figure 28As depicted, a TSN end station can send an SRP message and the SRP message can be propagated via one or more TSN bridges. In one example, the one or more TSN bridges can receive the SRP or talker announcement message via a control plane or user plane. The CNC or CUC can coordinate SRP message distribution based on the SRP message, SRP requirements, TSN requirements, etc. The CUC and / or CNC can manage the topology of the TSN bridges to meet one or more requirements, such as redundancy, reliability, latency, etc.
[0339] In example embodiments, a wireless device can receive, from a first station, a stream reservation protocol (SRP) message requesting reservation of network resources for a data packet stream of a time sensitive network (TSN). The SRP message can include an identifier of the data packet stream, at least one transmission parameter of the data packet stream, etc. In one example, the wireless device can determine to establish a packet data unit (PDU) session for the TSN based on the SRP message. The wireless device can send, to a session management function (SMF), a second message requesting establishment of the PDU session for the data packet stream. The second message can be via an AMF. The second message can include the SRP message, a parameter indicating that the PDU session is for the TSN, etc. The wireless device can receive an SRP response message indicating that a second station is ready to receive the data packet stream. The SRP response message can be received via a UP, a CP, the SMF, the AMF, a UPF, etc. The wireless device can send / forward the SRP response message to the first station.
[0340] In one example, a wireless device can receive, from a first station, a packet stream. The wireless device can transmit / forward the packet stream via a PDU session. The wireless device can receive, from the first station, an SRP message via a TSN translator.
[0341] In example embodiments, the at least one transmission parameter for the data packet stream can include an identifier of the data packet stream (stream ID), a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a latency value, a traffic specification parameter, etc. In one example, the data frame parameter can include a source MAC address of the data packet stream, a destination MAC address of the data packet stream, an identifier of a VLAN, etc. In one example, the user-to-network requirement parameter can include a parameter indicating a latency requirement of the data packet stream, a parameter indicating a redundancy requirement of the data packet stream, etc. In one example, the latency value can include a cumulative latency value, etc. In one example, the traffic specification parameter can include a parameter indicating a data frame size, a parameter indicating a number of data frames, etc.
[0342] In example embodiments, the second message can be a non-access stratum (NAS) message. In one example, the SRP response message can be a NAS message. The SRP response message can be received via a session management function. In one example, the SRP response message can be received via a PDU session. The SRP response message can be received via a user plane function.
[0343] In example embodiments, the SMF can extract at least one transport parameter for the data packet flow.
[0344] In one example, the SMF can send a QoS flow request for the data packet flow to a PCF. The SMF can receive at least one PCC rule for a QoS flow of the data packet flow from the PCF.
[0345] In one example, the second message can further include an identifier of a TSN bridge. The TSN bridge can be a 3GPP system including one or more ingress ports and one or more egress ports. The one or more egress ports can include a wireless device, a user plane function, etc. The one or more ingress ports can include a wireless device, a user plane function (UPF), etc. In one example, the second message can include an identifier of a port (of a UE in switch mode) associated with a first end station of a TSN system.
[0346] In one example, the SMF can send the SRP message to a user plane function (UPF).
[0347] In one example, a network exposure function (NEF) can receive the SRP message from the SMF. The NEF can send the SRP message to a network node. The network node can include a TSN translator device, a policy control function, an application function, etc. The network node can send the SRP message to a second TSN bridge. In one example, the second TSN bridge can receive the SRP message from the network node via the NEF / PCF / AF.
[0348] In example embodiments, a wireless device can receive a stream reservation protocol (SRP) message from a session management function, an AMF, a PCF, etc. requesting to reserve network resources for a data packet flow of a time sensitive network (TSN). The SRP message can include an identifier of the data packet flow (flow id), at least one transport parameter of the data packet flow, etc.
[0349] In one example, the wireless device can determine to establish a packet data unit (PDU) session for the TSN based on the SRP message. In one example, the wireless device can send a second message to a session management function (SMF) requesting to establish a PDU session for the data packet flow. The second message can include the SRP message, a parameter indicating that the PDU session is for the TSN, etc.
[0350] In one example, a wireless device can receive an acknowledgement message indicating a PDU session for a TSN system is successful. The wireless device can send an SRP message to a first station. The wireless device can receive an SRP response message from the first terminal station. The wireless device can send an SRP response to a second station.
[0351] In example embodiments, a session management function (SMF) can receive a message from a wireless device requesting a PDU session be established for a data packet flow for a time sensitive network (TSN). In one example, the message can include a stream reservation protocol (SRP) message. The SRP message can include an identifier for the data packet flow, at least one transport parameter for the data packet flow, a parameter indicating the PDU session is for a TSN, and / or the like. In one example, the at least one transport parameter for the data packet flow can include an identifier for the data packet flow. In example embodiments, the at least one transport parameter for the data packet flow can further include an identifier for the data packet flow (flow ID), a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a delay value, a traffic specification parameter, and / or the like. In one example, the data frame parameter can include a source MAC address for the data packet flow, a destination MAC address for the data packet flow, an identifier for a VLAN, and / or the like. In one example, the user-to-network requirement parameter can include a parameter indicating a delay requirement for the data packet flow, a parameter indicating a redundancy requirement for the data packet flow, and / or the like. In one example, the delay value can include a cumulative delay value, and / or the like. In one example, the traffic specification parameter can include a parameter indicating a data frame size, a parameter indicating a number of data frames, and / or the like.
[0352] The SMF can determine, based on the message, that the PDU session establishment can be for a TSN system. The SMF can determine, based on the at least one transport parameter for the data packet flow, a quality of service requirement parameter. The SMF can send, to a network function, an SRP message targeting a second station. The SMF can send, to a UPF, a second message requesting a PDU session be established for the TSN system. The second message can include the identifier for the data packet flow, the quality of service requirement parameter, and / or the like. The network function can be at least one of a NEF, a UPF, and / or the like.
[0353] According to various embodiments, a device (e.g., a wireless device, an off-network wireless device, a base station, etc.) can include one or more processors and memory. The memory can store instructions that, when executed by the one or more processors, cause the device to perform a series of actions. Embodiments of example actions are described in the drawings and specification. Features from various embodiments can be combined to create additional embodiments.
[0354] Figure 34is a flow diagram as per aspects of example embodiments of this disclosure. At 3410, a wireless device can receive, from a first station, a request indicating to configure a time sensitive network (TSN) bridge to transport a data packet flow. At 3420, the wireless device can send, to a session management function (SMF), a non-access stratum message including at least one parameter for configuration of the TSN bridge. At 3430, the wireless device can receive, from the SMF, a response message indicating that the TSN bridge is configured for transporting the data packet flow. At 3440, the wireless device can send, to the first station, a message indicating that the TSN bridge is successfully configured.
[0355] Figure 35 is a flow diagram as per aspects of example embodiments of this disclosure. At 3510, a wireless device of a time sensitive network (TSN) bridge can receive, from a session management function, a configuration message requesting to reserve network resources for a data packet flow of the TSN bridge. At 3520, the wireless device can determine to modify a packet data unit (PDU) session via the TSN bridge to transport the data packet flow based on the configuration message. At 3430, the wireless device can send, to a session management function (SMF), a NAS message including at least one transport parameter for the data packet flow.
[0356] Figure 36 is a flow diagram as per aspects of example embodiments of this disclosure. At 3610, a session management function (SMF) can receive, from a wireless device, a NAS message including at least one transport parameter for a data packet flow. At 3620, the SMF can determine to configure a UPF for TSN packet transport. At 3630, the SMF can send, to the UPF, a message configuring the UPF for the TSN bridge.
[0357] Figure 37 is a flow diagram as per aspects of example embodiments of this disclosure. At 3710, a session management function can receive, from an access and mobility management function, a first request message indicating that a first request message is for a time sensitive network (TSN) bridge. At 3720, the SMF can select a user plane function (UPF) supporting TSN functionality based on elements of the request message. At 3730, the SMF can send, to the UPF, a second request message configuring the UPF for the TSN bridge.
[0358] In one example, a wireless device can receive, from a first station, a request indicating to configure a time sensitive network (TSN) bridge for transmission of a data packet flow. The wireless device can send, to a session management function (SMF), a non-access stratum message including at least one parameter for configuring the TSN bridge. The wireless device can receive, from the SMF, a response message indicating that the TSN bridge is configured for transmission of the data packet flow. The wireless device can send, to the first station, a message indicating that the TSN bridge is successfully configured. In one example, the request can include a stream reservation protocol (SRP) message requesting to configure a time sensitive network (TSN) bridge for transmission of a data packet flow between the first station and a second station. The SRP message can include an identifier of the data packet flow, at least one parameter for configuration of the TSN bridge, and / or the like. The at least one transmission parameter for the data packet flow includes an identifier of the data packet flow, a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a delay value, a traffic specification parameter, and / or the like. The response message can be a SRP response message indicating that the second station is ready to transmit the flow.
[0359] In example embodiments, a wireless device can receive, from a first station, a stream reservation protocol (SRP) message requesting to configure a time sensitive network (TSN) bridge for transmission of a data packet flow between the first station and a second station. The SRP message can include an identifier of the data packet flow, at least one parameter for configuration of the TSN bridge, and / or the like. In one example, the wireless device can send, to a session management function (SMF), a non-access stratum message including the SRP message to configure the TSN bridge. The wireless device can receive a SRP response message indicating that the second station is ready to transmit the flow. The wireless device can send, to the first station, the SRP response message. In one example, the SRP response can be received from a control plane network element of the TSN bridge. The SRP response can be received from the second station of the TSN system. The wireless device can determine that a TSN type of PDU session is needed for transmission of the data packet flow. The non-access stratum message can further include a parameter indicating that the PDU session is for a TSN bridge or a TSN end station. The wireless device can determine to transmit the SRP via a control plane message. The identifier of the data packet flow can include an identifier of the first station, an identifier of the second station, and / or the like.
[0360] In an example embodiment, a wireless device can receive, from a first station, a stream reservation protocol (SRP) message requesting to reserve network resources for a data packet stream between the first station and a second station via a time sensitive network (TSN) bridge. The SRP message can include an identifier of the data packet stream, at least one transmission parameter of the data packet stream, and / or the like. The wireless device can determine to establish a packet data unit (PDU) session for the TSN based on the SRP message. The wireless device can send, to a session management function (SMF), a second message requesting to establish the PDU session for the data packet stream. The second message can include the SRP message, a parameter indicating that the PDU session is for the TSN, and / or the like. The wireless device can receive an SRP response message indicating that the second station is ready to receive the data packet stream. The wireless device can send the SRP response message to the first station. In an example, the wireless device can receive the packet stream from the first station. The wireless device can transmit the packet stream via the PDU session. In an example, the wireless device can receive the SRP message from the first station via a TSN translator. The at least one transmission parameter for the data packet stream can include an identifier of the data packet stream, a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a latency value, a traffic specification parameter, and / or the like. The data frame parameter can include a source MAC address of the data packet stream, a destination MAC address of the data packet stream, an identifier of a VLAN, and / or the like. The user-to-network requirement parameter can include a parameter indicating a latency requirement of the data packet stream, a parameter indicating a redundancy requirement of the data packet stream, and / or the like. The latency value can include a cumulative latency value. The traffic specification parameter can include a parameter indicating a data frame size, a parameter indicating a data frame quantity, and / or the like. The second message can be a non-access stratum (NAS) message. The SRP response message can be a NAS message. The SRP response message can be received via a session management function. The SRP response message can be received via a PDU session. The SRP response message can be received via a user plane function. The wireless device can extract the at least one transmission parameter for the data packet stream. The wireless device can map the at least one transmission parameter to a quality of service (QoS) parameter. The second message can further include an identifier of the TSN bridge. The TSN bridge can be a 3GPP system including an ingress port and an egress port. The egress port can include the wireless device or a user plane function. The ingress port can include the wireless device or the user plane function. The second message can include an identifier of a port associated with a first end station of the TSN system. The SMF can send the SRP message to a user plane function (UPF).
[0361] A wireless device of a time sensitive network (TSN) bridge can receive a configuration message from a session management function requesting to reserve network resources for a data packet flow of the TSN bridge. The wireless device can determine to modify a packet data unit (PDU) session to transport the data packet flow via the TSN bridge based on the configuration message. The wireless device can send a NAS message including at least one transport parameter for the data packet flow to a session management function (SMF). In one example, the configuration message can include an identifier of the data packet flow, at least one transport parameter of the data packet flow, etc. The at least one transport parameter for the data packet flow can include an identifier of the data packet flow, a data frame parameter, a user-to-network demand parameter, a priority and class indication parameter, a latency value, a traffic specification parameter, etc. The NAS message can include an SRP message, a parameter indicating the PDU session is for TSN, etc. The SRP message can include an identifier of the data packet flow, a data frame parameter, a user-to-network demand parameter, a priority and class indication parameter, a latency value, a traffic specification parameter, etc. The wireless device can receive an acknowledgement message indicating the PDU session is successful for the TSN system. The wireless device can send the SRP message to a first station. The wireless device can receive an SRP response message from the first station. The wireless device can send the SRP response message to a second station.
[0362] In example embodiments, a wireless device can receive a stream reservation protocol (SRP) message from a session management function requesting to reserve network resources for a data packet flow of a time sensitive network (TSN). The SRP message can include an identifier of the data packet flow, at least one transport parameter of the data packet flow, etc. The wireless device can determine to establish a packet data unit (PDU) session for the TSN based on the SRP message. The wireless device can send a second message to a session management function (SMF) requesting to establish the PDU session for the data packet flow. The second message can include the SRP message, a parameter indicating the PDU session is for TSN, etc. The wireless device can receive an acknowledgement message indicating the PDU session is successful for the TSN system. The wireless device can send the SRP message to a first station. The wireless device can receive an SRP response message from the first terminal station. The wireless device can send the SRP response to a second station.
[0363] In example embodiments, a session management function (SMF) can receive a NAS message from a wireless device including at least one transport parameter for a data packet flow. The SMF can determine to configure a UPF for TSN packet transport. The SMF can send a message to the UPF configuring the UPF for a TSN bridge. The NAS message can include an identifier of a time sensitive network (TSN) bridge. The SMF can receive an acknowledgement message from the UPF indicating the bridge is successfully configured. The message can include an element of the at least one transport parameter for the data packet flow.
[0364] In example embodiments, a session management function (SMF) can receive, from a wireless device, a NAS message including an identifier of a time sensitive network (TSN) bridge. The SMF can determine to configure a UPF for TSN packet transmission. The SMF can send, to the UPF, a message to configure the UPF for the TSN bridge. The SMF can receive, from the UPF, an acknowledgement message indicating successful configuration of the bridge. The NAS message can be a request to establish a PDU session for time sensitive network (TSN) packet transmission via the TSN bridge. The NAS message can include an identifier of a port of the wireless device. The port can be associated with the TSN bridge. The message can be a N4 session establishment request. The message can include an identifier of the TSN bridge, an identifier of the port associated with the packet transmission, etc. The acknowledgement message can include an identifier of the TSN bridge. The message can include a stream reservation protocol (SRP). The SRP can include an identifier of a data packet flow, a data frame parameter, a user-to-network requirement parameter, a priority and class indication parameter, a delay value, a traffic specification parameter, etc. The message can include an identifier of the data packet flow. The SMF can send, to a PCF, a QoS flow request for the data packet flow. The SMF can receive, from the PCF, at least one PCC rule for a QoS flow of the data packet flow.
[0365] In example embodiments, a session management function (SMF) can receive, from a wireless device, a message requesting to establish a PDU session for time sensitive network (TSN) packet transmission via a TSN bridge. The SMF can determine to configure a UPF for TSN packet transmission. The SMF can send, to the UPF, a session establishment request including an identifier of the TSN bridge, an identifier of a port associated with the packet transmission, etc. The SMF can receive, from the UPF, an acknowledgement indicating successful configuration of the port for the packet transmission.
[0366] In example embodiments, a session management function (SMF) can receive, from a wireless device, a message requesting establishment of a PDU session for a data packet flow of a time sensitive network (TSN). The message can include a stream reservation protocol (SRP) message including an identifier of the data packet flow, at least one transport parameter of the data packet flow, a parameter indicating that the PDU session is for a TSN, and / or the like. The SMF can determine, based on the message, that the PDU session establishment is for a TSN system. The SMF can determine, based on the at least one transport parameter of the data packet flow, a quality of service requirement parameter. The SMF can send, to a network function, an SRP message targeting a second station. The SMF can send, to a UPF, a second message requesting establishment of a PDU session for the TSN system. The second message can include the identifier of the data packet flow, the quality of service requirement parameter, and / or the like. In one example, the network function can be at least one of a network exposure function (NEF) or a user plane function (UPF). The SMF can send, to a PCF, a QoS flow request for the data packet flow. The SMF can receive, from the PCF, at least one PCC rule for a QoS flow of the data packet flow. The QoS flow request can include the at least one transport parameter for the data packet flow.
[0367] In example embodiments, a session management function can receive, from a wireless device of a time sensitive network (TSN) system, a first message indicating a request to establish a PDU session for a data packet flow, the first message including an identifier of the data packet flow, at least one parameter characterizing a transport requirement of the data packet flow, and / or the like. The SMF can determine, based on the first message, that the PDU session establishment request is for a TSN system. The SMF can determine, based on the at least one parameter characterizing the transport requirement of the data packet flow, a quality of service requirement parameter. The SMF can send, to a UPF, a second message requesting establishment of a PDU session for the TSN system, the second message including the identifier of the data packet flow and the quality of service requirement parameter. In one example, the SMF can send, to a PCF, a request for a QoS flow. The SMF can receive, from the PCF, at least one PCC rule for the QoS flow. The NEF can receive, from the SMF, an SRP message. The NEF can send, to a network node, the SRP message. The network node can include a TSN translator device, a policy control function, or an application function. The network node can send, to a second TSN bridge, the SRP message. The network node can receive, from the second TSN bridge, the SRP message.
[0368] In an example embodiment, a session management function can receive, from an access and mobility management function, a first request message indicating that the first request message is for a time sensitive network (TSN) bridge. The SMF can select a user plane function (UPF) that supports TSN functionality based on an element of the request message. The SMF can send, to the UPF, a second request message to configure the UPF for the TSN bridge. In one example, the first request message can be for a PDU session establishment request. The first request message can be a N11 request message. The second request message can be a N4 session establishment request message. The SMF can send, to a network repository function (NRF), a discovery request to select the UPF. The SMF can receive, from the NRF, an identifier of the UPF that supports TSN functionality. The discovery request message can include a TSN capability indicator.
[0369] In an example embodiment, a session management function (SMF) can receive, from an access and mobility management function, a PDU session establishment request indicating that the PDU session is for a time sensitive network (TSN) bridge. The SMF can send, to a network repository function (NRF), a discovery request message to select a user plane function, the discovery request message can include a TSN capability indicator. The SMF can receive, from the NRF, an identifier of the UPF that supports TSN functionality. The SMF can send, to the UPF, a session establishment request message.
[0370] In this specification, “a” and “an” and similar phrases are to be interpreted as “at least one” and “one or more.” In this specification, the term “may” is to be interpreted as “may, for example.” In other words, the term “may” indicates one of a plurality of suitable possibilities for one or more of the various embodiments if used after the term “may.” If A and B are sets, and every element of A is also an element of B, then A is said to be a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {celll, cell2} are: {celll}, {cell2}, and {celll, cell2}.
[0371] In this specification, a parameter (information element: IE) can include one or more objects, and each of these objects can include one or more other objects. By way of example, if a parameter (IE) N includes a parameter (IE) M, and the parameter (IE) M includes a parameter (IE) K, and the parameter (IE) K includes a parameter (information element) J, then, by way of example, N includes K, and N includes J. In an example embodiment, when one or more messages include a plurality of parameters, this means that the parameter of the plurality of parameters is in at least one of the one or more messages, but not necessarily in each of the one or more messages.
[0372] Many of the elements described in the disclosed embodiments can be implemented as modules. Herein, a module can be defined as a unit of functionality that is separable from other modules. Modules can be implemented in software and / or hardware. A module of executable code can be implemented in a language such as C, C++, Fortran, Java, Basic, MATLAB, Pascal, Visual Basic, assembly language, machine code, or the like. A module of executable code can be stored in any type of computer-readable medium or memory device, such as a static random access memory (SRAM), an electrically programmable read only memory (EPROM), an erasable EPROM (EEPROM), a flash memory, a magnetic disk, or an optical disk. A module can also include microcode, which is a set of instructions or commands that adjust the operation of a computer or machine, or that implement a software routine. A module can also be implemented in hardware, such as an application-specific integrated circuit (ASIC) or other hardware component. A module can also be implemented in a combination of software and hardware.
[0373] Exemplary embodiments of the present application can be implemented using various physical and / or virtual network elements, software defined networks, virtual network functions.
[0374] The disclosure of this patent document incorporates material that is copyrighted. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
[0375] While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Numerous changes to the disclosed embodiments can be made in the details of construction and arrangement without departing from the spirit and scope of the disclosure. Indeed, various embodiments of the application can be practiced in the absence of an element involving a specific combination of steps or materials. Additionally, it should be understood that where expenses are described by language such as means or step for can be accomplished, the recitation of such should not be interpreted as implying that something is invented which is not otherwise existing. The various embodiments presented are meant only to be examples and do not imply limitations on the scope of the disclosure. Particularly, it should be noted that the above explanation has focused on examples using a 5G AN. However, one skilled in the art will recognize that embodiments of the present application can also 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 embodiments presented in this disclosure can be combined. One or more features (methods or systems) of one embodiment can be implemented in other embodiments. Only a limited number of example combinations have been shown to indicate the possibilities of combining features to create enhanced transmitting and receiving systems and methods in various embodiments.
[0376] Additionally, it should be understood that any figures which highlight the functionality and advantages are presented for example purposes only. The architecture disclosed is sufficiently flexible and configurable to be utilized in ways other than that shown.
[0377] Furthermore, the purpose of the Abstract of the Disclosure is to enable the United States Patent and Trademark Office and the public generally, especially scientists, engineers, and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature of the technical disclosure. The Abstract is not intended to be limiting as to the scope or content of the disclosure.
[0378] Finally, it is the applicant's intent that only claims which include the explicit language "means for" or "step for" are to be interpreted under 35 U.S.C. 112, paragraph 6. It is the applicant's intent that claims not including the explicit language "means for" or "step for" are not to be interpreted under 35 U.S.C. 112, paragraph 6.
Claims
1. A method for time-sensitive network configuration based on a control plane, comprising: Receiving, by the wireless device, one or more TSN parameters from a time-sensitive network (TSN) converter device; Sending, by the wireless device, a non-access stratum (NAS) message to an access and mobility management function (AMF), where the NAS message indicates a request for establishing a PDU session, and the NAS message includes the one or more TSN parameters; and A message indicating acceptance of the PDU session is received by the wireless device from the AMF.
2. The method according to claim 1, wherein The one or more TSN parameters include a priority parameter.
3. The method according to claim 1 or 2, wherein: The one or more TSN parameters include a TSN stream identification parameter.
4. The method according to any one of claims 1 to 2, wherein The NAS message includes a port identification associated with the wireless device. 5 . The method according to claim 1 , wherein the NAS message indicates that the requested PDU session type is for the TSN.
6. A wireless device comprising one or more processors and a memory storing instructions, the instructions, when executed by the one or more processors, causing the wireless device to perform the method of any one of claims 1 to 5.
7. A non-transitory computer-readable medium comprising instructions which, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 5.
8. A method for time-sensitive network configuration based on a control plane, comprising: Receiving, by an access and mobility management function (AMF), a non-access stratum (NAS) message from a wireless device, the NAS message indicating a request for establishing a PDU session, the NAS message including one or more TSN parameters; and The AMF sends a message to the wireless device indicating acceptance of the PDU session.
9. The method according to claim 8, wherein The one or more TSN parameters include a priority parameter.
10. The method according to claim 8 or 9, wherein the one or more TSN parameters include a TSN stream identification parameter.
11. The method according to any one of claims 8 to 9, wherein the NAS message includes a port identification associated with the wireless device.
12. The method according to any one of claims 8 to 9, wherein the NAS message indicates that the requested PDU session type is for the TSN.
13. An access and mobility management function (AMF), comprising one or more processors and a memory storing instructions, wherein the instructions, when executed by the one or more processors, cause a base station to perform the method according to any one of claims 8 to 12.
14. 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 of any one of claims 8 to 12.
15. A system for time-sensitive network configuration based on a control plane, comprising: A wireless device comprising: one or more processors and a memory storing instructions, the instructions, when executed by the one or more processors, causing the wireless device to: receiving one or more TSN parameters from a time-sensitive networking (TSN) converter device; and sending a non-access stratum (NAS) message to an access and mobility management function (AMF), the NAS message indicating a request for establishing a PDU session, the NAS message including the one or more TSN parameters; and receiving a message from the AMF indicating acceptance of the PDU Session; The AMF, wherein the AMF comprises: one or more processors and a memory, wherein the memory stores instructions, and when the instructions are executed by the one or more processors, causes the AMF to: receiving the NAS message from the wireless device, the NAS message indicating the request to establish the PDU session, the NAS message including the one or more TSN parameters; and The message indicating acceptance of the PDU session is sent to the wireless device.