Identification method for time-sensitive networking bridge

Abstract

A first base station receives time sensitive networking (TSN) bridge parameters. A handover request is received from a second base station. A handover acceptance is sent to the second base station based on: the TSN bridge parameters; and the handover request.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 910,238, filed on October 3, 2019, the entire contents of which are hereby incorporated by reference. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0004] Figure 1 is a diagram of an example 5G system architecture according to aspects of an embodiment of the present disclosure.

[0005] Figure 2 is a diagram of an example 5G system architecture according to aspects of an embodiment of the present disclosure.

[0006] Figure 3 A system diagram of example wireless devices and network nodes in a 5G system according to aspects of an embodiment of the present disclosure.

[0007] Figure 4 is a system diagram of an example network node according to aspects of an embodiment of the present disclosure.

[0008] Figure 5A and Figure 5B Two registration management state models in UE 100 and AMF 155 according to aspects of embodiments of the present disclosure are depicted.

[0009] Fig. 6A and Figure 6B Two connection management state models in UE 100 and AMF 155 according to aspects of the disclosed embodiments are depicted.

[0010] Figure 7 is a diagram for classifying and marking traffic according to aspects of an embodiment of the present disclosure.

[0011] Figure 8 is an example call graph according to aspects of an embodiment of the present disclosure.

[0012] Fig. 9 is an example call graph according to aspects of an embodiment of the present disclosure.

[0013] Fig.10 is an example call graph according to aspects of an embodiment of the present disclosure.

[0014] Fig.11 is an example call graph according to aspects of an embodiment of the present disclosure.

[0015] Fig.12 is an example call graph according to aspects of an embodiment of the present disclosure.

[0016] Fig.13 is an example call graph according to aspects of an embodiment of the present disclosure.

[0017] Fig.14 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0018] Fig.15 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0019] Fig.16 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0020] Fig.17 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0021] Fig.18 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0022] Fig.19 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0023] Fig. 20 is an example diagram according to one aspect of an embodiment of the present disclosure.

[0024] Fig.21 is an example diagram according to one aspect of an embodiment of the present disclosure.

[0025] Fig. 22 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0026] Fig.23 is an example diagram according to one aspect of an embodiment of the present disclosure.

[0027] Fig.24 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0028] Fig.25 is an example diagram according to one aspect of an embodiment of the present disclosure.

[0029] Fig.26 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0030] Fig. 27 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0031] Fig.28 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0032] Fig.29 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0033] Fig.30 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0034] Fig.31 is an example call graph according to aspects of an embodiment of the present disclosure.

[0035] Fig.32 is an example call graph according to aspects of an embodiment of the present disclosure.

[0036] Fig.33 is an example call graph according to aspects of an embodiment of the present disclosure.

[0037] Fig.34 is an example call graph according to aspects of an embodiment of the present disclosure.

[0038] Fig.35 is an example call graph according to aspects of an embodiment of the present disclosure.

[0039] Fig.36 is an example call graph according to aspects of an embodiment of the present disclosure.

[0040] Fig.37 is an example call graph according to aspects of an embodiment of the present disclosure.

[0041] Fig.38 is an example call graph according to aspects of an embodiment of the present disclosure.

[0042] Fig.39 is an example call graph according to aspects of an embodiment of the present disclosure.

[0043] Fig.40 is an example call graph according to aspects of an embodiment of the present disclosure.

[0044] Fig.41 is an example call graph according to aspects of an embodiment of the present disclosure.

[0045] Fig.42 is an example call graph according to aspects of an embodiment of the present disclosure.

[0046] Fig.43 is an example call graph according to aspects of an embodiment of the present disclosure.

[0047] Fig.44 is an example call graph according to aspects of an embodiment of the present disclosure.

[0048] Fig.45 is an example call graph according to aspects of an embodiment of the present disclosure.

[0049] Fig.46 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0050] Fig.47 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure.

[0051] Fig.48 Detailed description of the invention The invention is an example diagram according to aspects of embodiments of the present disclosure. DETAILED DESCRIPTION

[0052] Example embodiments of the present invention enable enhanced features and functions to be implemented in 5G systems. Embodiments of the technology disclosed herein may be used in the technical field of 5G systems and network slicing for communication systems. More specifically, embodiments of the technology disclosed herein may relate to a 5G core network and a 5G system for network slicing in a communication system. Throughout this disclosure, UE, wireless device, and mobile device may be used interchangeably.

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

[0054] 5G 5th generation mobile network

[0055] 5GC 5G Core Network

[0056] 5GS 5G System

[0057] 5G-AN 5G Access Network

[0058] 5QI 5G QoS Indicator

[0059] AF Application Function

[0060] AMF Access and Mobility Management Function

[0061] AN Access Network

[0062] CDR Charge Data Record

[0063] CCNF Common Control Network Function

[0064] CIoT Cellular IoT

[0065] CN Core Network

[0066] CP Control Plane

[0067] DDN Downlink Data Notification

[0068] DL Downlink

[0069] DN Data Network

[0070] DNN data network name

[0071] F-TEID Fully Qualified TEID

[0072] GPSI General Public Subscription Identifier

[0073] GTP GPRS Tunneling Protocol

[0074] GUTI Globally Unique Temporary Identifier

[0075] IMSI International Mobile Subscriber Identity

[0076] LADN Local Area Data Network

[0077] LI Lawful Interception

[0078] MEI Mobile Equipment Identifier

[0079] MICO only mobile initiated connections

[0080] MME Mobility Management Entity

[0081] MO Mobile Origination

[0082] MSISDN Mobile Subscriber ISDN

[0083] MT Mobile Termination

[0084] N3IWF Non-3GPP Interworking Function

[0085] NAI Network Access Identifier

[0086] NAS Non-Access Stratum

[0087] NB-IoT Narrowband IoT

[0088] NEF Network Exposure Function

[0089] NF Network Function

[0090] NGAP Next Generation Application Protocol

[0091] NR New Radio

[0092] NRF Network Repository Features

[0093] NSI Network Slicing Example

[0094] NSSAI Network Slice Selection Assistance Information

[0095] NSSF network slice selection function

[0096] OCS Online Charging System

[0097] OFCS Offline Toll Collection System

[0098] PCF Policy Control Function

[0099] PDU Packet / Protocol Data Unit

[0100] PEI Persistent Equipment Identifier

[0101] PLMN Public Land Mobile Network

[0102] RAN Radio Access Network

[0103] QFI QoS Flow Identification

[0104] RM Registration Management

[0105] S1-AP S1 Application Protocol

[0106] SBA Service-Based Architecture

[0107] SEA Safety Anchor Function

[0108] SCM Security Context Management

[0109] SMF session management functions

[0110] SMSF SMS Function

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

[0112] SUCI Service User Correlation ID

[0113] SUPI Subscriber Persistent Identifier

[0114] TEID Tunnel Endpoint Identifier

[0115] TSN Time Sensitive Networking

[0116] UE User Equipment

[0117] UL Uplink

[0118] UL CL Uplink Classifier

[0119] UPF User Plane Function

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

[0121] In an example, a network function may be a processing function in a network, which may have functional behaviors and / or interfaces. A network function may be implemented as a network element on dedicated hardware and / or as Figure 3 and Figure 4 The network nodes depicted in are either implemented as software instances running on dedicated hardware and / or shared hardware, or as virtual functions instantiated on an appropriate platform.

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

[0123] In an example, the AMF 155 may support non-3GPP access networks through an N2 interface with the N3IWF 170, support NAS signaling with the UE 100 through the N3IWF 170, support authentication of UEs connected through the N3IWF 170, mobility management, authentication, and separate security context states for UEs 100 connected via a non-3GPP access 165 or simultaneously connected via a 3GPP access 105 and a non-3GPP access 165, support a coordinated RM context valid through the 3GPP access 105 and the non-3GPP access 165, support a CM management context for the UE 100 for connectivity through the non-3GPP access, and the like.

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

[0125] In an example, the session management function SMF 160 may include one or more of the following functions (one or more of the SMF 160 functions may be supported in a single instance of the SMF 160): session management (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF 110 and AN 105 nodes), UE 100 IP address allocation and management (including optional authorization), selection and control of UP functions, configuring traffic steering at the UPF 110 to route traffic to the appropriate destination, terminating the interface for the policy control function, controlling part of policy enforcement and QoS, lawful interception (for SM events and interface with LI system), terminating the SM part of the NAS message, downlink data notification, initiating AN-specific SM information, sent to the (R)AN 105 via AMF 155 over N2, determining the SSC mode of the session, roaming functions, handling local execution to apply QoS SLA (VPLMN), charging data collection and charging interface (VPLMN), lawful interception (in VPLMN, for SM events and interface with LI system), supporting communication with external DN 115 to transmit signaling for PDU session authorization / authentication by external DN 115, etc.

[0126] In an example, the user plane function UPF 110 may include one or more of the following functions (some of the UPF 110 functions may be supported in a single instance of UPF 110): an anchor point for intra-RAT / inter-RAT mobility (if applicable), an external PDU session point for interconnection to DN 115, data packet routing and forwarding, data packet inspection and user plane portion of policy rule execution, lawful interception (UP collection), traffic usage reporting, an uplink classifier to support routed traffic flows for data networks, a branch point to support multi-host PDU sessions, QoS processing for the user plane, uplink traffic validation (SDF to QoS flow mapping), transport level packet marking in uplink and downlink, downlink packet buffering, downlink data notification triggering, and the like.

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

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

[0129] 5GC may support allocation of static IPv4 addresses and / or static IPv6 prefixes based on subscription information in UDM 140 and / or based on configuration on a per-subscriber, per-DNN basis.

[0130] The user plane function (UPF 110) may handle the user plane path of the PDU session. The UPF 110 providing an interface to the data network may support the function of a PDU session anchor.

[0131] In an example, the policy control function PCF 135 can support a unified policy framework to control network behavior, provide policy rules for control plane functions to enforce policy rules, implement a front end to access subscription information related to policy decisions in a user data repository (UDR), and so on.

[0132] The network exposure function NEF 125 may provide a means to securely expose services and capabilities provided by 3GPP network functions, convert between information exchanged with AF 145 and information exchanged with internal network functions, receive information from other network functions, and so on.

[0133] In an example, the network repository function NRF 130 may support a service discovery function that may receive an NF discovery request from a NF instance, provide information about discovered NF instances (to be discovered) to the NF instance, and maintain information about available NF instances and their supported services, etc.

[0134] In an example, the NSSF 120 may select a set of network slice instances to serve the UE 100 and may determine the allowed NSSAI. In an example, the NSSF 120 may determine the set of AMFs 155 to be used to serve the UE 100 and / or determine a list of candidate AMFs 155 155 by querying the NRF 130 based on the configuration.

[0135] In an example, the data stored in the UDR may include at least user subscription data, including at least a subscription identifier, security credentials, access and mobility-related subscription data, session-related subscription data, policy data, and the like.

[0136] In an example, the AUSF 150 may support authentication server functionality (AUSF 150).

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

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

[0139] In an example, the 5GC may provide policy information from the PCF 135 to the UE 100. In an 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.

[0140] In the example, Figure 5A and Figure 5B As depicted in , the registration management RM can be used to register or deregister the UE / user 100 in the network and establish a user context in the network. Connection management can be used to establish and release the signaling connection between the UE 100 and the AMF 155.

[0141] In an example, the UE 100 may register on the network to receive the services for which it is requested to register. In an example, the UE 100 may periodically update its registration on the network to maintain reachability (periodic registration update), or update when moving (e.g., mobile registration update), or update its capabilities or renegotiate protocol parameters.

[0142] In the example, as in the example Figure 8 and Fig. 9 The initial registration procedure depicted in may involve performing network access control functions (e.g., user authentication and access authorization based on a subscription profile in UDM 140). Fig. 9 yes Figure 8 A continuation of the initial registration procedure depicted in . As a result of the initial registration procedure, the identity of the serving AMF 155 can be registered in the UDM 140.

[0143] In an example, the Registration Management RM procedure may be applied on both the 3GPP access 105 and the non-3GPP access 165 .

[0144] Example Figure 5AThe RM states of the UE 100 as observed by the UE 100 and the AMF 155 may be depicted. In an example embodiment, two RM states may be employed in the UE 100 and the AMF 155 that may reflect the registration state of the UE 100 in the selected PLMN: RM-DEREGISTERED 500 and RM-REGISTERED 510. In an example, in the RM-DEREGISTERED state 500, the UE 100 may not be registered in the network. The UE 100 context in the AMF 155 may not hold valid positioning or routing information for the UE 100, and thus the UE 100 may not be reachable through the AMF 155. In an example, the UE 100 context may be stored in the UE 100 and the AMF 155. In an example, in the RM-REGISTERED state 510, the UE 100 may be registered on the network. In the RM-REGISTERED 510 state, the UE 100 may receive services that may require registration on the network.

[0145] In an example embodiment, two RM states may be employed for the UE 100 in the AMF 155 that may reflect the registration status of the UE 100 in the selected PL MN: RM-DEREGISTERED 520 and RM-REGISTERED 530 .

[0146] As an example Fig. 6A and Figure 6B As depicted in , the connection management CM may include establishing and releasing a signaling connection between the UE 100 and the AMF 155 over the N1 interface. The signaling connection may be used to implement NAS signaling exchanges between the UE 100 and the core network. The signaling connection between the UE 100 and the AMF 155 may include both an AN signaling connection between the UE 100 and the (R)AN 105 (e.g., an RRC connection accessed via 3GPP) and an N2 connection of the UE 100 between the AN and the AMF 155.

[0147] As an example Fig. 6A and Figure 6BAs depicted in , for the NAS signaling connection between the UE 100 and the AMF 155, two CM states may be adopted, namely CM-IDLE 600, 620 and CM-CONNECTED 610, 630. The UE 100 in the CM-IDLE 600 state may be in the RM-REGISTERED 510 state and may not have a NAS signaling connection established with the AMF 155 through N1. The UE 100 may perform cell selection, cell reselection, PLMN selection, etc. The UE 100 in the CM-CONNECTED 610 state may have a NAS signaling connection with the AMF 155 through N1.

[0148] In an example embodiment, for the UE 100 at the AMF 155, two CM states may be employed, namely CM-IDLE 620 and CM-CONNECTED 630.

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

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

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

[0152] In an example, for the CM-IDLE 600, 620 states, two UE 100 reachability categories may be negotiated between the UE 100 and the AMF 155. 1) When the UE 100 is in CM-IDLE 600 mode, the UE 100 reachability allows mobile device terminated data. 2) Mobile Initiated Connection Only (MICO) mode. The 5GC may support a PDU connection service that provides a PDU exchange between the UE 100 and a data network identified by a DNN. The PDU connection service may be supported via a PDU session established at the request of the UE 100.

[0153] In an example, a PDU session may support one or more PDU session types. A PDU session may be established (e.g., upon request of UE 100), modified (e.g., upon request of UE 100 and 5GC) and / or released (e.g., upon request of UE 100 and 5GC) using NAS SM signaling exchanged between UE 100 and SMF 160 over N1. Upon request of an application server, 5GC may be able to trigger a specific application in UE 100. When a trigger is received, UE 100 may send it to an identified application in UE 100. The identified application in UE 100 may establish a PDU session for a specific DNN.

[0154] In the example, the 5G QoS model can support the following example: Figure 7 The QoS flow-based framework depicted in . The 5G QoS model can support both QoS flows that require guaranteed streaming bit rate and QoS flows that do not require guaranteed streaming bit rate. In an example, the 5G QoS model can support reflective QoS. The QoS model may include flow mapping or packet marking at the UPF 110 (CN_UP) 110, AN 105 and / or UE 100. In an example, packets can arrive from and / or be designated to the application / service layer 730 of the UE 100, UPF 110 (CN_UP) 110 and / or AF 145.

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

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

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

[0158] In an example, the 5G QoS indicator may be a scalar that may be used as a reference to a specific QoS forwarding behavior (e.g., packet loss rate, packet delay budget) to be provided to a 5G QoS flow. In an example, the 5G QoS indicator may be implemented in an access network by a 5QI reference node specific parameter (e.g., scheduling weight, admission threshold, queue management threshold, link layer protocol configuration, etc.) that may control the QoS forwarding process.

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

[0160] An example 5G system may be a 3GPP system including a 5G access network 105, a 5G core network, and UE 100, etc. The allowed NSSAI may be the NSSAI provided by the serving PLMN during, for example, a registration procedure, indicating the network allowed NSSAI for UE 100 in the serving PLMN in the current registration area.

[0161] In an example, the PDU connection service may provide an exchange of PDUs between the UE 100 and the data network. A PDU session may be an association between the UE 100 and the data network DN 115 that may provide the PDU connection service. The type of association may be IP, Ethernet and / or unstructured.

[0162] Establishing a user plane connection to a data network via a network slice instance may include executing an RM procedure to select an AMF 155 that supports the required network slice, and establishing one or more PDU sessions to the required data network via the network slice instance.

[0163] In an example, the network slice set of UE 100 may be changed at any time when UE 100 may be registered on the network, and may be initiated by the network or UE 100.

[0164] In an example, the periodic registration update may be a re-registration of the UE 100 upon expiration of a periodic registration timer. The requested NSSAI may be an NSSAI that the UE 100 may provide to the network.

[0165] In an example, a service-based interface may represent the way a set of services may be provided / exposed by a given NF.

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

[0167] In an example, the 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 interactions between identified control plane (CP) network functions. In the 5G system architecture, it may be considered to separate the user plane (UP) functions from the control plane functions. If necessary, the 5G system may enable network functions to interact directly with other NFs.

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

[0169] In the example, the 5G system can support a unified authentication framework, stateless NFs with separated computing and storage resources, capability exposure, and simultaneous 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.

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

[0171] In an example, a network slice may include core network control plane and user plane network functions, 5G radio access network; N3IWF functions for non-3GPP access networks, etc. Network slices may differ in terms of supported features and network function implementations. An operator may deploy multiple network slice instances that deliver the same features but for different groups of UEs, for example, when they deliver different committed services and / or because they may be dedicated to a customer. NSSF 120 may store mapping information between slice instance IDs and NF IDs (or NF addresses).

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

[0173] In an example, per PLMN, a PDU session may belong to one specific network slice instance. In an example, different network slice instances may not share PDU sessions. Different slices may have slice-specific PDU sessions using the same DNN.

[0174] S-NSSAI (Single Network Slice Selection Assistance Information) may identify a network slice. S-NSSAI may include: a slice / service type (SST), which may refer to the expected network slice behavior in terms of features and services; and / or a slice differentiator (SD). The slice differentiator may be optional information that may be supplemented with a slice / service type that allows further differentiation to select a network slice instance from potential multiple network slice instances that conform to the indicated slice / service type. In an example, the same network slice instance may be selected with different S-NSSAIs. The CN portion of the network slice instance serving the UE 100 may be selected by the CN.

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

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

[0177] In an example, the allowed NSSAI of the PLMN may take precedence over the configured NSSAI. The UE 100 may use the S-NSSAI corresponding to the network slice in the serving PLMN for subsequent network slice selection related procedures among the allowed NSSAI.

[0178] In an example, establishing a user plane connection to a data network via a network slice instance may include: executing an RM procedure to select an AMF 155 that can support the desired network slice, establishing one or more PDU sessions to the desired data network via the network slice instance, and so on.

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

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

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

[0182] In an example, during the registration procedure in the PLMN, if the network decides that the UE 100 can be served by a different AMF 155 based on network slicing aspects, 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.

[0183] In an example, a network operator may provide a network slice selection policy (NSSP) to the UE 100. The NSSP may include one or more NSSP rules.

[0184] In an example, if the UE 100 has one or more PDU sessions established corresponding to a particular S-NSSAI, the UE 100 may route user data for the application in one PDU session unless other conditions in the UE 100 may prohibit the use of the PDU session. If the application provides a DNN, the UE 100 may consider the DNN to determine which PDU session to use. In an example, if the UE 100 does not have a PDU session established with a particular S-NSSAI, the UE 100 may request a new PDU session corresponding to the S-NSSAI and having a DNN that may be provided by the application. In an example, in order for the RAN 105 to select appropriate resources for supporting network slices in the RAN 105, the RAN 105 may be aware of the network slices used by the UE 100.

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

[0186] In an example, to support network controlled privacy of slice information for slices accessible to UE 100, when UE 100 is aware or configured that privacy considerations may apply to NSSAI, UE 100 may not include NSSAI in NAS signaling unless UE 100 has a NAS security context, and UE 100 may not include NSSAI in unprotected RRC signaling.

[0187] In an example, for a roaming scenario, a network slice specific network function may be selected in the VPLMN and the HPLMN based on the S-NSSAI provided by the UE 100 during PDU connection establishment. If a standardized S-NSSAI is used, the selection of a slice specific NF instance may be performed by one or more PLMNs based on the provided S-NSSAI. In an example, the VPLMN may map the S-NSSAI of the HPLMN to the S-NSSAI of the VPLMN (e.g., including a default S-NSSAI mapped to the VPLMN) based on a roaming agreement. In an example, the selection of a slice specific NF instance may be performed in the VPLMN based on the S-NSSAI of the VPLMN. In an example, any slice specific NF instance in the HPLMN may be selected based on the S-NSSAI of the HPLMN.

[0188] As an example Figure 8 and Fig. 9 As depicted in , a registration procedure may be performed by UE 100 to obtain authorization to receive services, to enable mobile tracking, to achieve reachability, and the like.

[0189] In an example, the UE 100 may 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, subsequent requests, MICO mode preferences, etc.), etc.) to the (R)AN 105. In an example, in the case of NG-RAN, the AN parameters may include, for example, SUCI or SUPI or 5G-GUTI, selected PLMN ID and requested NSSAI, etc. In an example, the AN parameters may include an establishment cause. The establishment cause may provide the reason for requesting to establish an RRC connection. In an example, the registration type may indicate whether the UE 100 is to perform an initial registration (i.e., the UE 100 is in the RM-Deregistered state), a mobile registration update (e.g., the UE 100 is in the RM-Registered state and a registration procedure is initiated due to mobility), a periodic registration update (e.g., the UE 100 is in the RM-Registered state and a registration procedure may be initiated due to expiration of a periodic registration update timer), or an emergency registration (e.g., the UE 100 is in a limited service state). In an example, if the UE 100 performs an initial registration to a PLMN (i.e., the UE 100 is in the RM-Deregistered state), the UE 100 does not yet have a 5G-GUTI, then the UE 100 may include its SUCI or SUPI in the registration request. If the home network has provided a public key to protect the SUPI in the UE, then the SUCI may be included. 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, then the UE 100 may perform an initial registration and may include the SUPI in the registration request message. For emergency registration, SUPI may be included if the UE 100 does not have a valid 5G-GUTI available; PEI may be included when the UE 100 does not have a SUPI and does not have a valid 5G-GUTI. In other cases, a 5G-GUTI may be included and it may indicate the last serving AMF 155. If the UE 100 has registered in a PLMN that is different from a new PLMN for 3GPP access (e.g., a PLMN that is not a registered PLMN or an equivalent PLMN of a registered PLMN) via a non-3GPP access, the UE 100 may not provide a 5G-GUTI allocated by the AMF 155 via the 3GPP access during the registration procedure over the non-3GPP access.If the UE 100 has registered in a PLMN (e.g., a registered PLMN) that is different from a new PLMN for non-3GPP access (e.g., a PLMN that is not a registered PLMN or an equivalent PLMN of a registered PLMN) via 3GPP access, the UE 100 may not provide the 5G-GUTI allocated by the AMF 155 via the non-3GPP access during the registration procedure via 3GPP access. The UE 100 may provide the UE's usage settings based on its configuration. In the case of an initial registration or a mobile registration update, the UE 100 may include a mapping of the requested NSSAI, which may be a mapping of one or more S-NSSAIs in the requested NSSAI of the HPLMN to the S-NSSAI in the configured NSSAI, to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is allowed based on the subscribed S-NSSAI. If available, the last visited TAI may be included to help the AMF 155 generate the registration area of ​​the UE. In an example, security parameters may be used for authentication and integrity protection. The requested NSSAI may indicate network slice selection assistance information. The PDU session status may indicate a previously established PDU session in the UE. When the UE 100 is connected to two AMF 155s belonging to different PLMNs via 3GPP access and non-3GPP access, the PDU session status may indicate the PDU sessions that the current PLMN has established in the UE. A PDU session to be reactivated may be included to indicate a PDU session for which the UE 100 may intend to activate a UP connection. When the UE 100 is outside the available area of ​​the LADN, the PDU session corresponding to the LADN may not be included in the PDU sessions to be reactivated. When the UE 100 may have pending uplink signaling and the UE 100 may not include a PDU session to be reactivated, a subsequent request may be included, or the registration type may indicate that the UE 100 may want to perform an emergency registration.

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

[0191] In an example, the (R)AN 105 may 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, subsequent requests and MICO mode preferences), etc.) to the new AMF 155. In an example, when NG-RAN is used, the N2 parameters may include a selected PLMN ID, location information, cell identity, and a RAT type related to the cell in which the UE 100 is located. In an example, when NG-RAN is used, the N2 parameters may include an establishment cause.

[0192] In an example, the new AMF 155 may send a Namf_Communication_UEContextTransfer (Complete Registration Request) 815 to the old AMF 155. In an 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 may invoke a Namf_Communication_UEContextTransfer service operation 815 (including a Complete Registration Request IE which may be integrity protected) on the old AMF 155 to request the UE's SUPI and MM context. The old AMF 155 may use the integrity protected Complete Registration Request IE to verify that the context transfer service operation call corresponds to the requesting UE 100. In an example, the old AMF 155 may transfer event subscription information of one or more NF consumers for the UE to the new AMF 155. In an example, if the UE 100 identifies itself with a PEI, the SUPI request may be skipped.

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

[0194] In an example, if the SUPI is not provided by the UE 100 or retrieved from the old AMF 155, the Identity Request Procedure 820 may be initiated by the AMF 155 sending an Identity Request message to the UE 100 requesting the SUCI.

[0195] In an example, the UE 100 may respond with an identity response message 820 including the SUCI. The UE 100 may derive the SUCI by using the provided public key of the HPLMN.

[0196] In an example, the AMF 155 may decide to initiate UE 100 authentication 825 by invoking the AUSF 150. The AMF 155 may select the AUSF 150 based on the SUPI or SUCI. In an example, if the AMF 155 is configured to support emergency registration for unauthenticated SUPIs and the registration type Emergency Registration indicated by the UE 100, the AMF 155 may skip authentication and security setup, or the AMF 155 may accept that authentication may fail and may continue with the registration procedure.

[0197] In an example, authentication 830 may be performed by a Nudm_UEAuthenticate_Get operation. AUSF 150 may discover UDM 140. If AMF 155 provides SUCI to AUSF 150, AUSF 150 may return SUPI to AMF 155 after authentication is successful. In an example, if network slicing is used, AMF 155 may decide whether the registration request needs to be rerouted in the case where the initial AMF 155 references AMF 155. In an example, AMF 155 may initiate NAS security functions. In an example, upon completion of the NAS security function setup, AMF 155 may start an NGAP procedure to enable the 5G-AN to use it to protect procedures with the UE. In an example, the 5G-AN may store the security context and may confirm it to AMF 155. The 5G-AN may use the security context to protect messages exchanged with the UE.

[0198] In an example, the new AMF 155 may send a Namf_Communication_RegistrationCompleteNotify 835 to the old AMF 155. If the AMF 155 has changed, the new AMF 155 may inform the old AMF 155 that the registration of the UE 100 in the new AMF 155 may be completed by invoking the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication / security procedure fails, the registration may be rejected and the new AMF 155 may invoke the Namf_Communication_RegistrationCompleteNotify service operation with a rejection indicating the cause code towards the old AMF 155. The old AMF 155 may continue as if the UE 100 context transfer service operation was never received. If one or more of the S-NSSAIs used in the old registration area may not be served in the target registration area, the new AMF 155 may determine which PDU sessions may not be supported in the new registration area. The new AMF 155 may call the Namf_Communication_RegistrationCompleteNotify service operation to the old AMF 155, including the rejected PDU session ID and the rejection reason (e.g., S-NSSAI becomes no longer available). The new AMF 155 may modify the PDU session state accordingly. The old AMF 155 may notify the corresponding SMF 160 to release the UE's SM context locally by calling the Nsmf_PDUSession_ReleaseSMContext service operation.

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

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

[0201] In an example, based on the SUPI, the new AMF 155 may select 905 the UDM 140. The UDM 140 may select a UDR instance. In an example, the AMF 155 may select the UDM 140.

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

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

[0204] In an example, the new AMF 155 may perform a 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 may include the PCF-ID in the Npcf_AMPolicyControl Get operation. If the AMF 155 notifies the PCF 135 of mobility restrictions (e.g., UE 100 location) for adjustment, or if the PCF 135 updates its own mobility restrictions due to certain conditions (e.g., applications in use, time and date), the PCF 135 may provide the updated mobility restrictions to the AMF 155.

[0205] In an example, the PCF 135 may invoke the Namf_EventExposure_Subscribe service operation 935 for the UE 100 event subscription.

[0206] In an example, the AMF 155 may send a Nsmf_PDUSession_UpdateSMContext 936 to the SMF 160. In an example, if the PDU session to be reactivated is included in the registration request, the AMF 155 may call Nsmf_PDUSession_UpdateSMContext. The AMF 155 may send a Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session to activate the user plane connection for the PDU session. The SMF 160 may decide to trigger, for example, the intermediate UPF 110 to insert, remove or change the PSA. In the case where the intermediate UPF 110 is inserted, removed or relocated for a PDU session that is not included in the PDU session to be reactivated, the procedure may be performed without N11 and N2 interaction to update the N3 user plane between the (R)AN 105 and the 5GC. The AMF 155 may call the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160 when any PDU session status indicates that it is released at the UE 100. The AMF 155 may call the Nsmf_PDUSession_ReleaseSMContext service operation to the SMF 160 in order to release any network resources related to the PDU session.

[0207] In an example, the new AMF 155 155 may send an N2 AMF 155 Move Request 940 to the N3IWF. If the AMF 155 has changed, the new AMF 155 may create an NGAP UE 100 association for the N3IWF connecting the UE 100. In an example, the N3IWF may respond to the new AMF 155 with an N2 AMF 155 Move Response 940.

[0208] In an example, the new AMF 155 may send a Registration Accept 955 (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 modes, indication of support for IMS voice over PS session, emergency service support indicator, etc.) to the UE 100. In an example, the AMF 155 may 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, the 5G-GUTI may be included. If the AMF 155 allocates a new registration area, it may 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 may consider the old registration area to be valid. In an example, the mobility restrictions may be included in the case where the mobility restrictions may be applicable to the UE 100 and the registration type may not be an emergency registration. The AMF 155 may indicate the established PDU session to the UE 100 in the PDU session status. The UE 100 may locally remove any internal resources related to the PDU session that is not marked as established in the received PDU session status. In an 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 may locally remove any internal resources related to the PDU session of the current PLMN, which are not marked as established in the received PDU session status. If the PDU session status information is in the registration request, the AMF 155 may indicate the PDU session status to the UE. The mapping of the allowed NSSAI may be a mapping of one or more S-NSSAIs in the allowed NSSAI of the HPLMN to the S-NSSAI in the configured NSSAI. The AMF 155 may include LADN information of a LADN in the registration accept message 955, which is available within the registration area determined by the AMF 155 for the UE. If the UE 100 includes the MICO mode in the request, the AMF 155 may respond whether the MICO mode may be used. The AMF 155 may set an indication that IMS voice is supported over a PS session. In an example, in order to set an indication that IMS voice is supported over a PS session, the AMF 155 may 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 an example, the emergency service support indicator may inform the UE 100 that emergency services are supported, for example, the UE 100 may request a PDU session for emergency services. In an example, a handover restriction list and a UE-AMBR may be provided by the AMF 155 to the NG-RAN.

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

[0210] As an example Fig.10 and Fig.11 As depicted in , a service request procedure (e.g., a service request procedure triggered by UE 100) can be used by UE 100 in CM-IDLE state to request establishment of a secure connection to AMF 155. Fig.11 It describes the service request process Fig.10 Continuation of FIG. The service request procedure may be used to activate a user plane connection for an established PDU Session. The service request procedure may be triggered by the UE 100 or the 5GC and may be used when the UE 100 is in CM-IDLE and / or CM-CONNECTED and may allow selective activation of a user plane connection for some established PDU Sessions.

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

[0212] In an example, for any service request, the AMF 155 may respond with a service accept message to synchronize the PDU session state between the UE 100 and the network. If the service request may not be accepted by the network, the AMF 155 may respond to the UE 100 with a service reject message. The service reject message may include an indication or a reason code requesting the UE 100 to perform a registration update procedure. In an example, for a service request due to user data, if the user plane connection activation may not be successful, the network may take further action. In an example Fig.10 and Fig.11In the example, more than one UPF may be involved, for example, the old UPF 110 - 2 and the PDU session anchor PSA UPF 110 - 3 .

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

[0214] In an example, if the service request may be triggered for user data, the UE 100 may use the list of PDU sessions to be activated to identify the PDU session for which the UP connection is to be activated in the NAS service request message. If the service request may be triggered for signaling, the UE 100 may not identify any PDU session. If this procedure may be triggered for a paging response, and / or the UE 100 may have user data to be transmitted at the same time, the UE 100 may identify the PDU session for which the UP connection may be activated in the MM NAS service request message through the list of PDU sessions to be activated.

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

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

[0217] In an example, if the service request is not sent integrity protected or the integrity protection verification fails, the AMF 155 may initiate a NAS authentication / security procedure 1015 .

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

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

[0220] In an example, if the UE 100 can identify the PDU session to be activated in the NAS service request message, the Nsmf_PDUSession_UpdateSMContext request may be called by the AMF 155. In an example, the Nsmf_PDUSession_UpdateSMContext request may be triggered by the SMF 160, wherein the PDU session identified by the UE 100 may be related to other PDU session IDs other than the one that triggered the procedure. In an example, the Nsmf_PDUSession_UpdateSMContext request may be triggered by the SMF 160, wherein during the network-triggered service request procedure, the current UE 100 location may be outside the valid area of ​​the N2 information provided by the SMF 160. The AMF 155 may not send the N2 information provided by the SMF 160 during the network-triggered service request procedure.

[0221] In an example, the AMF 155 may determine a PDU session to be activated and may send a Nsmf_PDUSession_UpdateSMContext request to the SMF 160 associated with the PDU session, with the cause set to indicate establishment of user plane resources for the PDU session.

[0222] In an example, if the procedure may be triggered in response to a paging indicating non-3GPP access, and the list of allowed PDU sessions provided by the UE 100 may not include the PDU session for which the UE 100 has been paged, the AMF 155 may inform the SMF 160 that the user plane of the PDU session may not be reactivated. The service request procedure may succeed without reactivating the user plane of any PDU session, and the AMF 155 may inform the UE 100.

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

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

[0225] In an example, if the SMF 160 can accept UP activation for the PDU session, then based on the location information received from the AMF 155, the SMF 160 can check the UPF 110 selection 1025 criteria (e.g., slice isolation requirements, slice coexistence requirements, dynamic load of the UPF 110, relative static capacity of the UPF 110 among UPFs supporting the same DNN, UPF 110 locations available at the SMF 160, UE 100 location information, capabilities of the UPF 110, and required functionality for a specific UE 100 session. In an example, the appropriate UPF 110 can be selected by matching the functionality and features required by the UE 100, the DNN, the PDU session type (e.g., IPv4, IPv6, Ethernet type, or unstructured type), and (if applicable) the static IP address / prefix, the SSC mode selected for the PDU session, the UE 100 subscription profile in the UDM 140, the DNAI included in the PCC rules, the local operator policy, the S-NSSAI ... 100, the access technology used by the (R)AN 105, the logical topology of the UPF 110, etc.), and may determine 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 maintaining the UPF that acts as the PDU session anchor, a new intermediate UPF 110 may be selected (or the intermediate UPF 110 may be added / removed); re-establishment of the PDU session may be triggered to perform relocation / reallocation of the UPF 110 that acts 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.

[0226] In an example, the SMF 160 may send an N4 session establishment request 1030 to the UPF 110 (e.g., a new intermediate UPF 110). In an example, if the SMF 160 may select the new UPF 110 to act as the intermediate UPF 110-2 for the PDU session, or if the 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, thereby providing packet detection, data forwarding, execution, and reporting rules to be installed on the new intermediate UPF. The PDU session anchor addressing information (on N9) for this PDU session may be provided to the intermediate UPF 110-2.

[0227] In an example, if SMF 160 selects new UPF 110 to replace old (intermediate) UPF 110-2, SMF 160 may include a data forwarding indication. The data forwarding indication may indicate to UPF 110 that a second tunnel endpoint may be reserved for buffering DL data from the old I-UPF.

[0228] In an example, the new UPF 110 (intermediate) may send an N4 session establishment response message 1030 to the SMF 160. In the case where the UPF 110 may allocate CN tunnel information, the UPF 110 may provide the DL CN tunnel information of the UPF 110 used as a PDU session anchor and the UL CN tunnel information (e.g., CN N3 tunnel information) to the SMF 160. If a data forwarding indication may be received, the new (intermediate) UPF 110 used as an N3 termination point may send the DL CN tunnel information of the old (intermediate) UPF 110-2 to the SMF 160. The SMF 160 may start a timer to release resources in the old intermediate UPF 110-2.

[0229] In an example, if the SMF 160 can select a new intermediate UPF 110 for the 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 PSA UPF 110-3, thereby providing data forwarding indication and DL tunnel information from the new intermediate UPF 110.

[0230] In an example, if a new intermediate UPF 110 may be added for the PDU session, the (PSA)UPF 110-3 may start sending DL data to the new I-UPF 110 as indicated by the DL tunnel information.

[0231] In an example, if the service request may be triggered by the network, and the SMF 160 may remove the old I-UPF 110-2 and may not replace the old I-UPF 110-2 with the new I-UPF 110, then the SMF 160 may include a data forwarding indication in the request. The data forwarding indication may indicate to the (PSA) UPF 110-3 that a second tunnel endpoint may be reserved for buffering DL data from the old I-UPF 110-2. In this case, the PSA UPF 110-3 may start buffering DL data that it may simultaneously receive from the N6 interface.

[0232] In an example, PSA UPF 110-3 (PSA) may send an N4 session modification response 1035 to SMF 160. In an example, if a data forwarding indication may be received, PSA UPF 110-3 may become an N3 termination point and may send CN DL tunnel information of the old (intermediate) UPF 110-2 to SMF 160. SMF 160 may start a timer to release resources (if any) in the old intermediate UPF 110-2.

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

[0234] In an example, if the I-UPF 110-2 may be relocated and a forwarding tunnel may be established to the new I-UPF 110, the old (intermediate) UPF 110-2 may forward its buffered data to the new (intermediate) UPF 110 serving as the N3 termination point. In an example, if the old I-UPF 110-2 may be removed and the new I-UPF 110 may not be allocated for the PDU session, and a forwarding tunnel may be established to the UPF 110 (PSA) 110-3, the old (intermediate) UPF 110-2 may forward its buffered data to the UPF 110 (PSA) 110-3 serving as the N3 termination point.

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

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

[0237] In an example, if the PDU session may correspond to a LADN and the UE 100 may be outside the availability area of ​​the LADN, or if the AMF 155 may inform the SMF 160 that the UE 100 may be reachable for a regulatory prioritization service and the PDU session to be activated may not be used for a regulatory prioritization service; or if the SMF 160 may decide to perform a PSA UPF 110-3 relocation for the requested PDU session, the SMF 160 may send a message to the AMF 155 to reject activation of the UP for the PDU session by including a cause in the Nsmf_PDUSession_UpdateSMContext response.

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

[0239] In an example, if there are multiple PDU sessions that may involve multiple SMFs 160, the AMF 155 may not wait for responses from all SMFs 160 before it may send N2 SM information to the UE 100. The AMF 155 may wait for all responses from the SMFs 160 before it may send an MM NAS Service Accept message to the UE 100.

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

[0241] In an 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 may decide to enable the RRC inactive state of the UE 100.

[0242] If the AMF 155 may receive an indication from the SMF 160 during the PDU session establishment procedure that the UE 100 may be using a PDU session associated with a delay-sensitive service for any PDU session established for the UE 100, and the AMF 155 has received an indication from the UE 100 that CM-CONNECTED in the RRC inactive state may be supported, the AMF 155 may include the RRC inactive assistance information of the UE. In an example, the AMF 155 based on the network configuration may include the RRC inactive assistance information of the UE.

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

[0244] In an example, if the N2 request may include an MM NAS SERVICE ACCEPT message, the RAN 105 may forward the MM NAS SERVICE ACCEPT message to the UE 100. The UE 100 may locally delete the context of the PDU session that may not be available in the 5GC.

[0245] In an example, if N1 SM information may be transmitted to the UE 100 and may indicate that some PDU sessions may be reestablished, the UE 100 may initiate PDU session reestablishment for the PDU sessions that may be reestablished after the service request procedure may be completed.

[0246] In an example, after the user plane radio resources may be set up, uplink data from the UE 100 may be forwarded to the RAN 105. The RAN 105 (eg, NG-RAN) may send the uplink data to the provided UPF 110 address and tunnel ID.

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

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

[0249] In an example, if dynamic PCC is deployed, SMF 160 may initiate a notification (if subscribed) about the new location information to PCF 135 by calling an event exposure notification operation (e.g., Nsmf_EventExposure_Notify service operation). PCF 135 may provide updated policies by calling a policy control update notification message 1115 (e.g., Npcf_SMPolicyControl_UpdateNotify operation).

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

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

[0252] In an example, the old intermediate UPF 110-2 may send an N4 Session Modification Response or an N4 Session Release Response 1155 to the SMF 160. The old UPF 110-2 may confirm with an N4 Session Modification Response or an N4 Session Release Response message to confirm the modification or release of the resources. The AMF 155 may call a Namf_EventExposure_Notify service operation to notify the NFs that may have subscribed to the event of the mobile-related event after this procedure may be completed. In an example, if SMF 160 has subscribed to UE 100 moving into or out of an area of ​​interest and if the current location of the UE may indicate that it may be moving into or out of the subscribed area of ​​interest, or if SMF 160 has subscribed to LADN DNN and if UE 100 may be moving into or out of an area where LADN is available, or if UE 100 may be in MICO mode and AMF 155 has notified SMF 160 of UE 100 that it is unreachable and SMF 160 may not send DL data notifications to AMF 155, and AMF 155 may notify SMF 160 that UE 100 is reachable, then AMF 155 may call Namf_EventExposure_Notify to SMF 160, or if SMF 160 has subscribed to the UE 100 reachability status, then AMF 155 may notify UE 100 of reachability.

[0253] exist Fig.12 and Fig.13An example PDU session establishment procedure is depicted in . In an example embodiment, when the PDU session establishment procedure may be employed, the UE 100 may send a NAS message 1205 (or an SM NAS message) to the AMF 155, the 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, N1 SM container (PDU session establishment request), etc. In the example, the UE 100 may generate a new PDU session ID in order to establish a new PDU session. In the example, when emergency services may be required and an emergency PDU session may not have been established, the UE 100 may initiate a UE 100 requested PDU session establishment procedure, wherein the request type indicates an emergency request. In the example, the UE 100 may initiate a UE 100 requested PDU session establishment procedure by transmitting a NAS message containing a PDU session establishment request within an N1 SM container. The PDU session establishment request may include a PDU type, an SSC mode, a protocol configuration option, and the like. In an example, if the PDU session establishment is a request to establish a new PDU session, the request type may indicate an initial request, and if the request involves an existing PDU session between a 3GPP access and a non-3GPP access or involves an existing PDN connection in the EPC, the request type may indicate an existing PDU session. In an example, if the PDU session establishment may be a request to establish a PDU session for emergency services, the request type may indicate an emergency request. If the request involves an existing PDU session for emergency services between a 3GPP access and a non-3GPP access, the request type may indicate an existing emergency PDU session. In an example, the NAS message sent by the UE 100 may be encapsulated by an AN in an N2 message sent to the AMF 155, which may include user location information and access technology type information. In an example, the PDU session establishment request message may include an SM PDU DN request container, which includes information about the external DN authorization for the PDU session. In an example, if the procedure may be triggered for SSC mode 3 operation, the UE 100 may include an old PDU session ID in the NAS message, which may indicate the PDU session ID of the ongoing PDU session to be released. The old PDU session ID may be an optional parameter that may be included in this case. In an example, the AMF 155 may receive a NAS message (e.g., a NAS SM message) from the AN along with user location information (e.g., a cell ID in the case of the RAN 105). In an example, when the UE 100 is outside the availability area of ​​the LADN, the UE 100 may not trigger a PDU session establishment for a PDU session corresponding to the LADN.

[0254] In an example, the AMF 155 may determine that the NAS message or the SM NAS message may correspond to a request for a new PDU session based on the request type indicating an initial request and the PDU session ID may not be used for any existing PDU session of the UE 100. If the NAS message does not contain an S-NSSAI, the AMF 155 may determine the default S-NSSAI for the requested PDU session based on the UE 100 subscription (if it may contain only one default S-NSSAI), or based on operator policy. In an example, the AMF 155 may perform SMF 160 selection 1210 and select SMF 160. If the request type may indicate an initial request or the request may be attributable to a handover from the EPS, the AMF 155 may store an association of the S-NSSAI, the PDU session ID, and the SMF 160 ID. In an example, if the request type is an initial request, and if an old PDU session ID indicating an existing PDU session may be included in the message, the AMF 155 may select the SMF 160, and may store an association of the new PDU session ID and the selected SMF 160 ID.

[0255] In an example, AMF 155 may send an N11 message 1215 to SMF 160, such as an Nsmf_PDUSession_CreateSMContext request (including: SUPI or PEI, DNN, S-NSSAI, PDU session ID, AMF 155ID, request type, N1 SM container (PDU session establishment request), user location information, access type, PEI, GPSI), or an Nsmf_PDUSession_UpdateSMContext request (SUPI, DNN, S-NSSAI, PDU session ID, AMF 155ID, request type, N1 SM container (PDU session establishment request), user location information, access type, RAT type, PEI). In an example, if the AMF 155 may not be associated 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 may call a 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 may call a Nsmf_PDUSession_UpdateSMContext request. In an example, the AMF 155 ID may be the GUAMI of the UE, which uniquely identifies the AMF 155 serving the UE 100. The AMF 155 may forward the PDU session ID and the N1 SM container containing the PDU session establishment request received from the UE 100. When the UE 100 registers for emergency services without providing a SUPI, the AMF 155 may provide a PEI instead of a SUPI. If the UE 100 is registered for emergency services but has not yet been authenticated, the AMF 155 may indicate that the SUPI has not yet been authenticated.

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

[0257] In an example, the SMF 160 may send an N11 message response 1220 to the AMF 155, such as 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.

[0258] In an example, if the SMF 160 can perform secondary authorization / authentication 1230 during PDU session establishment by the DN-AAA server, the SMF 160 can select the UPF 110 and can trigger the PDU session establishment authentication / authorization.

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

[0260] In an example, if a dynamic PCC is deployed, SMF 160 may perform PCF 135 selection 1235. If the request type indicates an existing PDU session or an existing emergency PDU session, SMF 160 may use the PCF 135 that has been selected for the PDU session. If a dynamic PCC is not deployed, SMF 160 may apply local policies.

[0261] In an example, SMF 160 may perform a session management policy establishment procedure 1240 to establish a PDU session with PCF 135, and may obtain the default PCC rules for the PDU session. GPSI may be included if available at SMF 160. If the request type in 1215 indicates an existing PDU session, SMF 160 may notify the event previously subscribed by PCF 135 through a session management policy modification procedure, and PCF 135 may update the policy information in SMF 160. PCF 135 may provide SMF 160 with an authorized session-AMBR and authorized 5QI and ARP. PCF 135 may subscribe to IP allocation / release events in SMF 160 (and may subscribe to other events).

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

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

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

[0265] In an example, if the request type in 1215 indicates that the existing PDU session involves an existing PDU session moved between a 3GPP access and a non-3GPP access, the SMF 160 may maintain the SSC mode of the PDU session, for example, the current PDU session anchor and the IP address. In an example, the SMF 160 may trigger, for example, the insertion of a new intermediate UPF 110 or the allocation of a new UPF 110. In an example, if the request type indicates an emergency request, the SMF 160 may select 1245 the UPF 110 and may select SSC mode 1.

[0266] In an example, SMF 160 may perform a session management policy modification 1250 procedure to report some events to the previously subscribed PCF 135. If the request type is an initial request, a dynamic PCC is deployed and the PDU type is IPv4 or IPv6, SMF 160 may inform the (previously subscribed) PCF 135 of the allocated UE 100 IP address / prefix.

[0267] In an example, PCF 135 may provide the updated policy to SMF 160. PCF 135 may provide SMF 160 with the authorization session-AMBR and authorization 5QI and ARP.

[0268] In an example, if the request type indicates an initial request, the SMF 160 may initiate an N4 session establishment procedure 1255 with the selected UPF 110. The SMF 160 may initiate an N4 session modification procedure with the selected UPF 110. In an example, the SMF 160 may send an N4 session establishment / modification request 1255 to the UPF 110, and may provide packet detection, enforcement, reporting rules, etc. to be installed on the UPF 110 for this PDU session. If the CN tunnel information is allocated by the SMF 160, the CN tunnel information may be provided to the UPF 110. If this PDU session requires selective user plane deactivation, the SMF 160 may determine an inactivity timer and provide it to the UPF 110. In an example, the UPF 110 may confirm by sending an N4 session establishment / modification response 1255. If the CN tunnel information is allocated by the UPF, the CN tunnel information may be provided to the SMF 160. In an example, if multiple UPFs are selected for a PDU session, the SMF 160 may initiate an N4 session establishment / modification procedure 1255 with one or more UPFs 110 for the PDU session.

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

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

[0271] In an example, the (R)AN 105 may issue an AN-specific signaling exchange 1315 with the UE 100, which may be related to the information received from the SMF 160. In an example, in the case of a 3GPP RAN 105, an RRC connection reconfiguration procedure may be performed with the UE 100 to establish the necessary RAN 105 resources related to the QoS rules of the PDU session request 1310. In an example, the (R)AN 105 may allocate (R)AN 105N3 tunnel information for the PDU session. In the case of dual connectivity, the primary RAN 105 node may allocate some (zero or more) QFIs to be set to the primary RAN 105 node and other QFIs to the secondary RAN 105 node. The AN tunnel information may include tunnel endpoints of one or more involved RAN 105 nodes, and QFIs allocated to one or more tunnel endpoints. The QFI may be allocated to the primary RAN 105 node or the secondary RAN 105 node. In an example, the (R)AN 105 may forward a 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 (R)AN 105 tunnel information is successfully allocated, the (R)AN 105 may provide the NAS message to the UE 100.

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

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

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

[0275] In an example, SMF 160 may send a Nsmf_PDUSession_UpdateSMContext response 1340 (cause) to AMF 155. In an example, SMF 160 may subscribe to UE 100 mobility event notifications (e.g., location report, UE 100 moving into or out of an area of ​​interest) from AMF 155 by calling Namf_EventExposure_Subscribe service operation after this step. For LADN, SMF 160 may subscribe to UE 100 moving into or out of a LADN service area event notification by providing LADN DNN as an indicator of the area of ​​interest. AMF 155 may forward the relevant events subscribed by SMF 160.

[0276] In an example, the SMF 160 may send a Nsmf_PDUSession_SMContextStatusNotify(release) 1345 to the AMF 155. In an example, if at any time during this procedure the PDU session establishment is unsuccessful, the SMF 160 may notify the AMF 155 by calling Nsmf_PDUSession_SMContextStatusNotify(release) 1345. The SMF 160 may release any N4 sessions created, any PDU session addresses (if assigned) (e.g., IP addresses), and may release the association with the PCF 135.

[0277] In an example, where the PDU type is IPv6, the SMF 160 may generate an IPv6 router advertisement 1350 and may send it to the UE 100 via N4 and the UPF 110.

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

[0279] 5GS can operate as a standalone Time-Sensitive Networking (TSN) network or as part of a non-standalone TSN network such as an industrial communication network. 5GS can support, for example Fig.15The three operation nodes are depicted in . Fig.15 In the fully distributed model shown at the bottom of the figure, TSN end stations (e.g., talkers and listeners) can communicate 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 to neighboring bridges along with the active topology of the TSN flow. Network resources can be managed locally in each TSN bridge. Fig.15 In the centralized network and distributed user model shown in the middle, TSN end stations (e.g., talkers and listeners) can communicate TSN flow requirements directly to the TSN network. The TSN flow requirements are forwarded to the centralized network configuration (CNC). The TSN bridge can provide its network capability information and active topology information to the CNC. The CNC can have a complete view of the TSN network and be enabled to calculate the corresponding end-to-end communication path from the talker to the listener to meet the TSN flow requirements provided by the end station. The calculation results can be provided by the CNC as TSN configuration information to each TSN bridge in the path between the TSN end stations involved (talker to listener) as network configuration information. Fig.15 In the fully centralized model shown at the top of FIG, TSN end stations (e.g., talkers and listeners) can communicate TSN flow requirements to the centralized user configuration (CUC). The CUC can adapt the TSN end station flow requirements before forwarding them to the CNC. The CNC performs the same actions as described in the centralized network / distributed user model, but 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 these TSN end stations accordingly.

[0280] In an example, the TSN system may employ 5GS as a TSN link, as a TSN bridge, etc. The TSN system may be integrated with 5GS.

[0281] As an example Fig.17 As depicted in , 5GS can be used as a TSN link (e.g., as an Ethernet connection / link between UE and UPF) for external networks. The link can be defined by the connected entities, i.e., two TSN bridges or a TSN terminal station and a TSN bridge, two TSN terminal stations, etc. The link capabilities can be described by the TSN flow requirements of the TSN bridge connected to the end of the link or by the TSN terminal station directly connected to the link. The exposed capabilities can include latency information, link speed, available bandwidth information, etc.

[0282] In such Fig.18 and Fig.19In the example depicted in , 5GS can be used as a TSN bridge. 5GS can use the 5GQoS framework to receive TSN-related reservation requests. 5GS can use 5G internal signaling to satisfy TSN reservation requests. When 5GS is adopted as a TSN bridge (e.g., a logical TSN bridge), the TSN bridge may include an adaptation function that converts 5GS protocols and information objects into TSN protocols and information objects (and vice versa). The 5GS bridge can provide TSN entry and exit ports to the DN via a TSN converter (device) on the UE side and via a "TSN converter" (CP and UP) on the CN side. The 5GS bridge can support different TSN configuration models. In the example, the TSN bridge can use one or more TSN compatible interfaces using corresponding protocols for TSN terminal stations, TSN bridges, CNCs, CUCs, etc. on the control plane and / or user plane. The functions required for TSN bridge self-management and interaction with the CNC can be located at the network converter.

[0283] In the example, Fig. 20 As depicted in , 5GS can be integrated with the TSN system. When 5GS is integrated with the TSN system, the various nodes of 5GS (such as UPF, gNB, etc.) can interact with TSN programs initiated by TSN endpoints and TSN controllers. This allows 5GS and associated infrastructure to present themselves as multiple TSN-compatible endpoints.

[0284] As an example Fig.14 As depicted in , 5GS can be integrated with a TSN system. The TSN system can generate control and data traffic and send it to the 5GS. The control and data traffic may include TSN QoS information, flow information, port information, etc. Ethernet frames and / or headers may be mapped to or encapsulated in 5G frames / packets and sent to the 5GS via the air interface. A 5G radio with an integrated Ethernet adapter can be connected to a wireless device (UE).

[0285] In an example embodiment, the 3GPP network may support the derivation of TSN bridge delay management object attributes (e.g., independentDelayMin / Max, dependentDelayMin / Max, etc.) for a 3GPP bridge based on 3GPP attributes (e.g., QoS flow packet delay budget (PDB) value, guaranteed flow bit rate (GFBR), maximum data burst capacity (MDBV) indicated in a QoS profile, etc.). The mapping of 3GPP attributes to TSN capabilities may be in SMF and / or PCF, and the exposure of capabilities to TSN bridges may be via NEF, SMF, PCF, etc.

[0286] In an example, a TSN bridge delay management object may include per-tuple frame length related attributes (ingress port, egress port, traffic class). Frame length related attributes may include: independentDelay Min / Max (e.g., bridge delay occurring independently of frame size (usually in ns)), dependentDelay Min / Max (e.g., bridge delay occurring per basic capacity (usually in ps per byte)), and the like.

[0287] exist Fig.21 In the example depicted in , when a centralized model or a fully centralized model and a centralized network / distributed user model are adopted in a TSN network, the 5GS can be enhanced to act as a TSN bridge in the network. The AF can act as a controller function to collect information related to the 5GS virtual bridge and register it to the CNC via the application interface defined by TSN, because the CNC maintains the capabilities of each TSN bridge in the TSN network and the topology of the network. In the example, based on the information maintained by the CNC, the CNC can calculate the forwarding and scheduling rules on each bridge of the TSN flow required to collect the CUC required for the TSN flow of the fully centralized model from the terminal station. In the example, a control plane-based QoS negotiation can be adopted. As Fig.21 As depicted in , CNC can negotiate with PCF through TSN AF to generate TSN-aware QoS profiles for flows. TSN AF can convert TSN service characteristics into TSN QoS requirements, TSN QoS profiles, etc.

[0288] In an example, for a control plane-based solution, the AF may act as a controller function to collect 5GS virtual bridge related information (e.g., the AF receives information from the SMF and may register it to the CNC via an application interface defined by TSN). The information may include: bridge identity, port identity, bridge delay, transmission delay, bridge-related topology information, etc. In an example, the bridge identity may identify a TSN bridge in a TSN network. In an example, the port identity may identify a port in a TSN bridge. The bridge delay may include a delay value when a frame passes through a bridge, which may include maximum and minimum independence delays and dependency delays. The transmission delay may be a delay for a frame to be transmitted from a TSN bridge port to an adjacent port on a different bridge. The bridge-related topology may include bridge and port identities and port capabilities of the TSN bridge and the adjacent bridge. In an example, the identity of the virtual bridge and the associated port of the UPF may be preconfigured on the UPF and may be reported to the AF via the SMF when the UPF is set. A UE or PDU session may be virtualized as a virtual port on a virtual bridge with a (unique) identity that may be assigned by an SMF or UPF. The TSN AF may interact with the 5G CN and may perform mapping between TSN network parameters and the new deterministic QoS profile of the 5GS, negotiate service processing and related QoS policies, etc. In an example, the TSN AF may talk to other 5GC NFs directly or via the NEF.

[0289] In an example, the 5GS virtual bridge information may include bridge ID, port ID, bridge internal information (e.g., bridge delay), bridge port related information (e.g., propagation delay), etc. The information of the 5GS virtual bridge may be reported to the AF by the 5GS control plane, such as bridge ID, port ID, bridge internal information (e.g., bridge delay), bridge port related information (e.g., propagation delay), etc.

[0290] exist Fig. 22In the example depicted in , the 5GS virtual bridge can be per UPF, per TSN network (indicated by DNN), and the 5GS virtual bridge user plane may include a UPF port and a UE port connected to such a UPF port via a PDU session. The identity of the virtual bridge and the relevant UPF port may be preconfigured on the UPF and may be reported to the AF via the SMF when the UPF is set or the PDU session is established. The UE port identity may be unique in the 5GS virtual bridge, and the UE port identity may be assigned by the UPF. The UPF port and UE port related information may be reported to the AF by the SMF directly or via the NEF. The UPF port related information may be reported to the SMF by the UPF using node-level signaling or PDU session-level signaling. The UE port related information may be reported to the SMF by the UE via the NAS or via the UP of its corresponding PDU session. In the example, the UE may operate in a switching mode, an Ethernet switch mode, etc. In the example, the UE port of the 5GS virtual bridge may be a physical port of the UE, a virtual port / interface of the UE, etc.

[0291] In the example, the traffic scheduling in the TSN bridge can be by traffic class, which is the service level of packet transmission. The TSN bridge port can support different traffic classes. In the example, if the TSN bridge is aware of VLAN, the TSN bridge port can support different VLANs. When the SMF selects the UPF for the PDU session, it can take into account the traffic class and VLAN subscribed by the UE.

[0292] As an example Fig. 22 As depicted in the figure, UPF1 and UPF2 support different VLANs and service classes based on deployment. When UE1 and UE2 establish a PDU session, UPF1 and UPF2 are selected respectively to meet their subscribed VLANs and service classes. Since the bridge delay defined in 802.1QCC is according to the traffic class of each port pair, UPF can determine the correct port pair to provide service for the PDU session, and SMF can report the bridge delay on such port pair. For example, for UE1 in the figure, UPF1 can determine port 1 of VLAN100 that supports service class 2 requested by UE1 in order to provide service for the PDU session. Then, SMF can report the bridge delay of service class 2 for the port pair (UE1 port and UPF1 port 1).

[0293] exist Fig.23In the example depicted in , for 5GS virtual bridge topology discovery, the UPF and UE can report topology information to the SMF as defined in 802.1AB 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 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 the one or more devices to discover / report the 5GS virtual bridge. One or more ports of the 5GS virtual bridge can support sending LLDP or receiving LLDP. For propagation delays 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 characteristics and mappings between such QoS characteristics and service categories. The packet delay budget (PDB) in the QoS characteristics can be used to implement maximum latency transmission for deterministic delivery. The SMF can obtain the QoS characteristics of the service class subscribed to by the UE, and the SMF can use the PDB therein as the bridge delay of the corresponding service class on the port pair. AF can collect / collect / obtain / receive and maintain 5GS virtual bridge related information. AF can act as the control plane of the 5GS virtual bridge and can register this information to the CNC or update this information 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 service category in the TSN flow rule and map the service category to the corresponding 5QI.

[0294] exist Fig.24In the example embodiment depicted in , the TSN bridge may report bridge capabilities, TSN bridge configuration parameters, TSN bridge ID, virtual port ID, port ID, etc. In the example, the identity of the 5GS virtual bridge and UPF port may be pre-configured based on the deployment on the UPF. The UPF may report its port capabilities and propagation delays (as defined in 802.1Qcc), topology information (as defined in 802.1AB), and corresponding DNNs to the SMF using node-level signaling, and the SMF may forward the received information to the AF directly or via the NEF to generate or update the 5GS virtual bridge and bridge port. The UE may send a PDU session establishment request to the AMF. The AMF may select the SMF for the PDU session. The SMF may receive the service class and VLAN subscribed by the UE from the UDM, and may receive QoS characteristics (e.g., 5QI, PDB) corresponding to the subscribed service class from the PCF. The SMF may select the UPF to support the subscribed service class and the subscribed VLAN. The SMF may send an N4 session establishment request to the UPF with the DNN, service class ID, and VLAN values ​​to request the allocation of the UE port ID and determine the service UPF port. UPF can determine the 5GS virtual bridge for the PDU session and can assign an identity to the UE port. Based on the service categories and VLANs supported by the UPF port in the DN, UPF can determine the UPF port that provides services for the PDU session. UPF can send the assigned UE port identity with the corresponding 5GS virtual bridge identity, the service UPF port ID with the corresponding service category ID, etc. to SMF. SMF can send the 5GS virtual bridge ID related to the PDU session and can assign the UE port ID to the UE. This information can be used by the UE to perform topology discovery and information reporting. SMF can use the PDB in the QoS characteristics as the bridge delay for the corresponding service category and port pair, and can send the 5GS virtual bridge related information (bridge delay, UE port ID, UPF port ID, service category, 5GS virtual bridge ID, UE ID) or send it to AF via NEF to add a UE port or update the bridge properties.

[0295] In an example, when a PDU session is established, the UE may report its port capabilities and propagation delays (as defined in 802.1Qcc) and topology information (as defined in 802.1AB) to the SMF via NAS or the user plane. The AF may receive / collect / collect and may maintain 5GS virtual bridge properties, including bridge ID, port ID of UPF port, port ID of UE port, port-related capabilities, and bridge delay of port pairs, etc. When the bridge properties change, the AF may send the 5GS virtual bridge properties to the CNC to create a TSN bridge or update the bridge.

[0296] In an example embodiment, the UE may operate as an Ethernet switch. The SMF may configure the UE to operate as an Ethernet switch with configuration parameters provided during establishment of a PDU session or configuration of a TSN bridge. The PDU session may provide access to a terminal station via a TSN bridge to communicate with one or more terminal stations. The UE operating as an Ethernet switch may be part of one or more TSN systems. One or more backend devices may be connected to the UE operating as an Ethernet switch. In an example, the SMF may provide (TSN) configuration parameters to the UPF or the UE in a switching mode. The (TSN) configuration parameters may include: an indicator indicating whether the UE in Ethernet switching mode can turn on or off the spanning tree algorithm; a periodic timer for sending a BDPU message; a TSN bridge identifier; a bridge identifier of the UE in Ethernet switch mode; an indicator indicating whether the UE in Ethernet switch mode can notify a change in the state of a port; an indicator indicating whether the UE in Ethernet switch mode can report a list of MAC addresses of TSN terminal stations, backend devices connected in a backend network, etc.

[0297] In an example, if the SMF instructs the UE to report a list of MAC addresses of backend devices or TSN terminal stations, the UE in switching mode can obtain a list of MAC addresses of backend devices connected or changed in the backend network. In an example, when a PDU session provides communication for more than one TSN system, the UE can obtain / determine the mapping relationship between the MAC address and the TSN system. When the UE receives an indicator or detects a change on the backend device, the UE can notify the SMF of the MAC address list and mapping relationship during the PDU session establishment / modification procedure. The SMF can provide the UPF with Ethernet packet filters and forwarding rules based on the MAC address and mapping relationship. The UPF can detect and forward Ethernet frames based on the Ethernet packet filters and forwarding rules received from the SMF.

[0298] In an example, a UE in Ethernet switch mode may report its port status, which may be caused by the execution of a spanning tree algorithm, etc., so that the SMF may control the port status of the UPF based on the report to prevent waste of network resources.

[0299] In the example, the UPF may support S tags (IEEE 802.1ad), C tags (IEEE 802.1q). In the example, the PDU session may provide access to one or more TSN systems, TSN terminal stations, etc. The S tags and / or C tags of the data packet stream may be used. The TSN system configuration may be preconfigured on the UE or provided to the UE by the network (e.g., SMF, etc.). In the example, the TSN system identifier may be used to identify the TSN system, one or more TSN terminal stations, etc. In the example, the operator may assign a list of TSN system or TSN terminal station identifiers to the UE. The identifier may be configured in the UDR, UDM, etc. The SMF may be configured by the operator as a mapping table having TSN identifiers, VLAN IDs, C tags, S tags, etc. The SMF may map a list of TSDN terminal station identifiers connected to the UE (notified of the UE by the procedure established by the PDU session) to S tags and C tags and packet filters for uplink services. The UPF may insert S tags and C tags into services sent to N6, etc. based on the packet filters for uplink services.

[0300] exist Fig.25 In the example depicted in , 3GPP or 5GS functions can act as one or more TSN bridges for a TSN network. A 5GS bridge can include a port on a single UPF (e.g., PSA) side, a user plane tunnel between the UE and the UPF, and a port on the DS-TT side. For one or more 5GS bridges for a TSN network, a port on the NW-TT can support connectivity to the TSN network, and a port on the DS-TT side can be associated with a PDU session that provides connectivity to the TSN network. The granularity of the logical TSN bridge can be based on the UPF ( Fig.25 (a)) or according to UE( Fig.25(b)). The bridge ID of the logical TSN bridge can be bound to the UPF ID of the UPF. The TSN AF can store the binding relationship between the port on the UE / DS-TT side, the port on the UPF / NW-TT side, and the PDU session during the reporting of the logical TSN bridge information. One or more PDU sessions that can be connected to the same TSN network via the UPF can be grouped into a single virtual bridge. The capabilities of one or more ports on the UE / DS-TT side and the UPF / NW-TT side can be integrated as part of the configuration of the 5G virtual bridge, and can be transmitted to / notified to the TSN AF and delivered to the CNC for TSN bridge registration and modification. In order to support TSN service scheduling through the 5GS TSN bridge, the 5GS can support the following functions: reporting the bridge information of the 5GS bridge to the TSN network, mapping the configuration information obtained from the TSN network to the 5GS QoS information (e.g., 5QI, TSC auxiliary information) of the QoS flow in the corresponding PDU session to effectively perform time-aware scheduling. The TSN network can use the bridge information of the 5GS TSN bridge to perform appropriate management configuration for the 5GS TSN bridge. The bridge information of the 5GS TSN bridge may include: the bridge ID of the 5GS bridge (TSN bridge ID); the capabilities of the 5GS bridge according to IEEE 802.1Qcc; the 5GS bridge delay according to the port pair for each service class, including the 5GS TSN bridge delay (dependent and independent of the frame size, and their maximum and minimum values: independentDelayMax, independentDelayMin, dependentDelayMax, dependentDelayMin); ingress port ID, egress port ID and service class; propagation delay (txPropagationDelay) of each port, including transmission propagation delay; egress port ID; topology of the 5GS bridge; service class and its priority for each port, etc. The identity of the 5GS bridge (e.g., TSN bridge ID) and the identity of the port on the NW-TT side may be preconfigured on the UPF, which may be selected for the PDU session service TSC based on the subscribed DNN, service class and VLAN. The port ID on the DS-TT side for the PDU session may be stored at the SMF. AF may be responsible for receiving bridge information of the 5GS bridge from the 5GS, and registering the information to the TSN network or updating the information.

[0301] In such Fig.26In the example embodiment depicted in , the source NG-RAN may determine / decide to initiate an Xn-based or N2-based handover to the target NG-RAN. This may be triggered, for example, due to new radio conditions or load balancing, and if there is no Xn connectivity with the target NG-RAN, an N2-based handover may be performed. Following an unsuccessful Xn-based handover (e.g., no IP connectivity between the T-RAN and the S-UPF) or based on dynamic information learned by the S-NG-RAN, an error indication may be received from the target NG-RAN. Fig.26 In the RAN, AMF can provide TSN bridge configuration parameters, TSN bridge ID, etc. to RAN nodes (e.g., S-NG-RAN and T-NG-RAN).

[0302] In the prior art, a base station may not be configured with bridge parameters associated with a bridge (e.g., a TSN bridge). In an implementation of the prior art, a handover procedure may be performed for a wireless device to a target base station that does not support a bridge used by the wireless device. Existing handover procedures may result in unreliable TSN bridge operation and may cause additional signaling. An example embodiment may support a source base station for handover of a wireless device to send bridge parameters indicating a bridge used by the wireless device to a target base station (e.g., via a handover request message). An example embodiment may enable a base station to receive bridge parameters indicating a bridge supported by the base station or supported by the other network node from another network node. The other network node may be at least one of another base station, a core network device, or an operation and management (OAM) server. The base station may use the bridge parameters during the handover procedure to determine a handover target base station that supports a bridge used or to be used by the wireless device. The handover target base station may use the bridge parameters during the handover procedure to determine whether to accept or reject a handover request.

[0303] Example embodiments include enhancement of base station configuration by a bridge network node (eg, another base station, core network node, OAM, etc.) Transmission of bridge parameters from the network node to the base station may assist the base station during a handover procedure and improve system performance.

[0304] When a bridge (or TSN bridge) is configured in a 3GPP system, the UPF may be configured with a bridge. After establishment / configuration of the bridge, the UPF may be associated with a bridge identifier. One or more base stations may provide services for the 3GPP system. However, some base stations may not have connectivity to the UPF of the 3GPP system configured for the bridge. In an example, during a handover procedure, when a wireless device conducts a PDU session with the bridge via a base station, the base station may not be associated with a bridge identifier. When a wireless device or base station determines to hand over to a target base station, the target base station may not be able to adopt the PDU session of the bridge.

[0305] A base station that is not part of the bridge may not have connectivity with the UPF of the bridge. Acceptance of the handover by the base station may require the network to reallocate the UPF of the bridge and perform PDU session modification and reconfiguration of the bridge. When the base station receives the bridge parameters through the core network node, it may be an indication that the base station has connectivity with the UPF of the bridge.

[0306] TSN bridges can be used for factory automation and can be designed for deterministic and delay-sensitive communications. When the bridge's radio performs a handover to a target base station that requires a change of UPF, signaling overhead and latency can cause interruptions and performance degradation or lead to system failure.

[0307] The transmission of bridge parameters to the base station by SMF, PCF, etc. may require additional signaling and system complexity. The AMF may receive a NAS message from the wireless device. The AMF may receive bridge parameters from the SMF or other network nodes. After the configuration of the bridge is successful, the SMF may send to the AMF: bridge parameters, such as bridge identifier, TSN system identifier, etc. The AMF may send the bridge parameters to the base station. If the base station does not receive the bridge parameters during the handover procedure, the base station may accept the handover request. If the base station is not part of the bridge, or the base station does not have connectivity with the UPF of the bridge, additional signaling may occur.

[0308] In an example, a bridge ID (or TSN bridge ID) may be configured according to a wireless device. In an example, a bridge ID (or TSN bridge ID) may be configured according to a UPF. In an example, a bridge may include one or more wireless devices that may not be shared between other bridges. A bridge may include one or more UPFs that may be shared between other bridges. If the wireless device of the bridge does not indicate bridge parameters to the network or base station, the base station may not be able to determine an appropriate handover decision for the target base station. For example, if a base station receives a bridge identifier, then during the handover procedure, the base station may select a target base station that supports the bridge. In an example, a TSN bridge associated with a wireless device may be interpreted as a wireless device using a TSN bridge and / or a TSN bridge. A TSN bridge may include a wireless device and / or a connection between a wireless device and a 3GPP network.

[0309] In an example, a base station may be shared between one or more bridges (or TSN bridges). In an example, a base station may provide resources to support one or more bridges. When a bridge is configured, the base station may receive bridge parameters associated with one or more bridges.

[0310] In an example, during a handover for a wireless device, if a target base station that does not have a bridge for the wireless device accepts the handover, a new UPF may need to be configured for the target base station to support the bridge for the wireless device. The new UPF that needs to be configured may cause additional signaling and performance degradation. Example embodiments may include enhancing the handover procedure by transmitting a bridge parameter or a bridge identifier for the wireless device to the target base station via a handover request message.

[0311] In an example, a bridge identifier, a TSN bridge identifier, etc. may be a derivative of a system identifier, a TSN system identifier, an unsigned integer value, etc. One or more bridge identifiers may have a common system identifier and may be distinguished by one or more bits, such as a least significant bit, etc. A match of bridge identifiers may include the bridge identifiers being identical or equal in whole or in part. Matching bridge identifiers may indicate that the bridge identifiers are in the same TSN system domain or group.

[0312] In an example, the base station may be required to support bridge capabilities according to the requirements of the bridge or TSN system. In an example, the TSN bridge capability indicator or bridge capability indicator may indicate that the base station of the 3GPP network can support bridge communication requirements. In an example, the TSN bridge capability indicator or bridge capability indicator may indicate that the base station is connected to one or more UPFs of the bridge that the 3GPP system is supporting. Transmitting the bridge capability indicator via a handover request message may assist the target base station in determining whether to accept or reject the handover. If the target base station does not provide the bridge capability indicated in the handover request message, the target base station may reject the handover request for the wireless device.

[0313] The TSN bridge may include a 3GPP system. The TSN bridge may include a wireless device, a UPF, a wireless device (UE) side, and a port on the UPF side. The 3GPP system network element may be dedicated to the TSN bridge, or may be shared between TSN bridges. The UPF may be configured for a TSN bridge having a TSN bridge identity, a port identity, etc. In an example of the prior art, the wireless device may be handed over to a RAN node that may not provide an A tunnel connection with the UPF of the TSN bridge. The RAN node to which the wireless device is handed over may not support the TSN bridge associated with the wireless device and / or the UPF. The handover of the wireless device to a RAN node (e.g., a target base station) that does not support the TSN bridge used by the wireless device may interrupt the operation of the TSN bridge. The prior art may reduce communication reliability and cause additional signaling. An enhanced handover procedure for TSN bridge operation may be required.

[0314] Example embodiments include an enhanced handover procedure that may employ a TSN bridge identifier (e.g., information about connectivity / topology of a UPF and a base station) to support a TSN bridge. Example embodiments may support a base station in selecting an appropriate target base station for a handover of a wireless device using a TSN bridge. Implementations of example embodiments may support a base station in sharing information of a TSN bridge supported by the base station with another base station. Example embodiments may improve communication reliability and reduce signaling overhead during a handover of a wireless device using TSN.

[0315] The target base station may receive a handover request message for a wireless device of a bridge from a source base station. The target base station may be part of a bridge and support bridges. The target base station may not be part of a bridge and may not support bridges, and may not have connectivity with the UPF of the bridge for the wireless device. In the prior art, the target base station may not be able to determine whether to accept or reject a handover request for a wireless device using a bridge (e.g., a TSN bridge). If the target base station accepts the handover and does not support bridges, additional signaling may occur and / or communication reliability may be reduced.

[0316] In an example, the UE may move from one RAN node (eg, source base station) to another RAN node (eg, target base station), and the movement may result in a handover to the other RAN node. The handover procedure may be performed due to load balancing, mobility, interference, etc.

[0317] The TSN bridge may include a 3GPP system. The TSN bridge may include a wireless device, a UPF, a wireless device (UE) side, and a port on the UPF side. The 3GPP system network element may be dedicated to the TSN bridge, or may be shared between TSN bridges. The UPF may be configured for a TSN bridge with a TSN bridge identity, a port identity, etc. The wireless device may be handed over to a RAN node that may not have an AN tunnel connection with the UPF of the TSN bridge. The RAN node may not be part of the TSN bridge associated with the wireless device and / or UPF. The RAN node may be shared by one or more TSN bridges. In an example, the UE may move from one RAN node (e.g., a source base station) to another RAN node (e.g., a target base station), and the movement may result in a handover to other RAN nodes. Due to load balancing, a handover procedure may be performed. Handing over to a target base station that is not part of the TSN bridge may cause additional signaling, so an enhanced handover procedure may be required.

[0318] Example embodiments include an enhanced handover procedure that may employ a TSN bridge identifier, information about the connectivity / topology of UPFs and base stations to select candidate target base stations, thereby reducing signaling during handover within a TSN system.

[0319] Example embodiments relate to a TSN bridge, which may include elements of a 3GPP system, a core network, a 5G system, and a RAN. Time-sensitive communication (TSC) may be related to connection establishment and data transmission for one or more TSN terminal stations via a TSN system. A TSN bridge may include a UPF that may be preconfigured for a TSN bridge. The UPF may be preconfigured using a TSN bridge ID, a virtual port, an Ethernet port, TSN bridge configuration parameters, and the like. A port of a UPF, such as a virtual port, an Ethernet port, and the like, may be identified using a MAC address, an IP address, a port ID, a virtual port ID, and the like. A port may be adopted by one or more PDU sessions. A PDU session may be shared between one or more ports of a TSN bridge, or may be dedicated to a port of a TSN bridge at a network side (e.g., UPF) or a device side.

[0320] In such Fig.26 and Fig. 27 In the example embodiment depicted in, a wireless device (UE) registered or attached to a 3GPP system can be connected to a TSN terminal station, for example, via a TSN converter, a TSN adapter, a device-side TSN converter, etc. The UE can be a 3GPP wireless device and can be connected to a 3GPP radio access network. The wireless device can be handed over to a different RAN node due to mobility or load balancing or based on measurement reports or wireless channel conditions. The UE can be handed over to a RAN node that is not connected to an AN tunnel of a UPF configured with a TSN bridge. Selecting a target RAN node that provides connectivity with a UPF of a TSN bridge can improve the performance of the system by reducing signaling and reducing the need to reallocate UPF. The reallocation of UPF may cause the reconfiguration of the TSN bridge. The reconfiguration of the TSN bridge may include signaling from the UPF to the SMF and from the SMF to the TSN system, CNC, CUC, AF, NEF, etc. The reconfiguration of the TSN bridge may cause the reestablishment of the policy association. The TSN configuration information can be transmitted to the UE and reconfigured on the UE. The example embodiment may include a modification to the handover procedure signaling. When the source RAN node determines to hand over to the target base station, it may send a handover request message. The handover request message may include TSN bridge configuration parameters, TSN bridge ID, TSN capability indicator, etc. When the target RAN node receives the handover request message, it may accept or reject the handover request based on the local configuration or the configuration provided by the network. The target RAN node may receive configuration information from AMF, NEF, OAM, etc. The configuration information may include TSN bridge configuration parameters, TSN bridge ID, TSN capability indicator, etc. For example, the target RAN node may be configured with a first TSN bridge ID. If the target RAN node receives a handover request including a second TSN bridge ID, it may reject the handover. If the handover request includes the first TSN bridge ID, the target RAN node may accept or adopt the handover. In such a case, Fig. 27 In the example, base station 1 and base station 2 are configured by the AMF to support TSN bridge 1 with TSN bridge ID 1. Base station 3 is not configured for TSN bridge ID 1. When base station 1 determines to hand over the UE from base station 1, base station 1 may select base station 2 as the target base station. In the example, when the signal strength of base station 3 may be higher / better than the signal strength of base station 2, base station 1 may select base station 2 based on the TSN bridge ID capability / support configuration information.

[0321] In such Fig.30 In the example embodiment depicted in , the RAN nodes may exchange configuration information via the Xn interface by adopting an Xn-based procedure. An example procedure may be an Xn setup procedure, an NG-RAN configuration update procedure, etc. During the Xn-based procedure, the NG-RAN node or the RAN node may provide TSN related parameters (such as TSN bridge configuration parameters, TSN bridge IDs that may be supported by the RAN node, TSN bridge capability indicators, TSN capability support indicators, etc.) to the neighboring RAN nodes. The provided information may be used by the RAN node to select a target RAN node from a set of candidates that may support a TSN bridge with which the UE is registered or has a PDU session connected. In an example, the determination of the target RAN node may be based on one or more elements of a message during the Xn-based procedure. The selected target RAN node may support TSN bridges, so that no relocation, reallocation, or handover rejection occurs.

[0322] In an example, the TSN bridge ID may be a unique identifier that identifies a TSN bridge. The identifier may be a series of alphanumeric characters, a derivation of a UPF identifier associated with a bridge, a derivation of an identifier of a TSN system, and the like. The TSN bridge ID may be associated with a pair of UPFs or a combination of one or more UPFs and one or more wireless devices. In an example, the (TSN) bridge identifier may be a 64-bit unsigned integer. In order to prioritize the bridge, if two bridge identifiers are numerically compared, the smaller number may represent a better / higher priority bridge. For example, the maximum valid 4 bits of the bridge identifier may include a settable priority component (13.20, 13.26.2) and may be modified for a CIST or for an MSTI independent of those used for other MSTIs (or for a CIST), thereby allowing the use of bridge identifier priorities to provide complete and independent control over the configuration of each of these trees. Each SPT may use the same bridge identifier as the CIST, so the SPT bridge identifier is not encoded separately. For management purposes, the priority component may be considered a 16-bit value, but the values ​​to which the priority component may be set may be limited to those values ​​in which the least significant 12 bits are zero (i.e., only the most significant 4 bits are settable). The most significant 12 bits following the bridge identifier (when encoded, the least significant 4 bits of the most significant octet plus the second most significant octet) may include a locally assigned system ID extension that may provide a different bridge identifier for each MSTI. The CIST is identified by a system ID extension of zero. Each MSTI may include a system ID extension value equal to its MSTID, which is a convention for conveying the MSTID for each MSTI parameter set in the MST BPDU. The least significant 48 bits of the bridge identifier may ensure its uniqueness and may be derived from a globally unique bridge address (8.13.8) and may be encoded in the third to eighth most significant octets of the encoded identifier. The octets of the TSN bridge may be derived from the initial octets of the MAC address, etc. The identifier may be a unique identifier, an address (e.g., a MAC address, an Ethernet address, an IP address, IPv4, IPv6, etc.). The port ID, the virtual port ID may include the MAC address of the port, the IP address of the port, the name of the port (e.g., alphanumeric), etc. The port may be: a physical port; a virtual port within a wireless device, a UPF, a TSN converter device, a TSN terminal station; a port that connects / interconnects a wireless device or UPF with a TSN system (IEEE device, non-3GPP device, etc.); an interconnection / connection between a TSN converter and a wireless device or UPF, etc.

[0323] In an example, the TSN bridge configuration parameters may include a port ID, a virtual port ID, a port management information container, a latency parameter or a requirement of the TSN bridge, an identifier of the TSN bridge (TSN bridge ID, etc.).

[0324] In such Fig.28In the example embodiment depicted in , in response to instantiation, creation or configuration of a TSN bridge, or after a PDU session is established via a TSN bridge by a UE connected to an end station of a TSN system, the AMF may perform an initial context setup procedure and may send an initial context setup request message to a base station, NG-RAN node, gNB, eNodeB, etc. The purpose of the initial context setup procedure may be to establish the necessary overall initial UE context at the NG-RAN node, including N1 signaling connection, PDU session context, security keys, mobility restriction list, UE radio capabilities, UE security capabilities, etc. The AMF may initiate the initial context setup procedure if there is a UE-associated logical NG connection for the UE, or if the AMF has received the RAN UE NGAPID IE in the INITIAL UE MESSAGE message, or if the NG-RAN node has initiated a UE-associated logical NG connection by sending an INITIAL UE MESSAGE message via another NG interface instance. The procedure may employ UE-associated signaling. During the initial context setup procedure, the AMF or SMF may provide TSN bridge configuration parameters to the NG-RAN node. For example, the initial context setup request message may include the TSN bridge configuration parameters. When a wireless device (UE) establishes a PDU session via a TSN bridge, the AMF may receive TSN bridge configuration parameters from the SMF, PCF, etc. In an example, the AMF may receive the TSN bridge configuration parameters during a registration procedure for the UE. The SMF may send an N11 message to the AMF via the N11 interface, indicating confirmation of the PDU session context setup (e.g., Nsmf_PDUSession_createSMContext message, etc.). In an example, the AMF may receive TSN bridge configuration parameters from the PCF during UE policy association establishment / modification. The AMF may receive TSN bridge configuration parameters from the UDM during the registration procedure. When the AMF receives the TSN bridge configuration parameters (e.g., TSN bridge ID, bridge ID, etc.), the AMF may send the TSN bridge ID to the NG-RAN node via the N2 procedure (such as an initial context setup request message). The NG-RAN node may be configured for the TSN bridge based on the TSN bridge configuration parameters. When the NG-RAN node receives a handover request for a second UE for the same TSN bridge from the source NG-RAN node, the NG-RAN node may accept the handover based on the bridge ID (e.g., one or more bridge IDs) set for the NG-RAN node. The NG-RAN node currently serving the PDU session of the UE of the TSN bridge may have connectivity with the UPF associated with the bridge. The NG-RAN node may notify neighboring NG-RAN nodes via Xn setup or NG-RAN node configuration update procedures, etc.During the handover procedure, the source NG-RAN node may select a NG-RAN node that has connectivity with the UPF of the TSN bridge among other RAN node candidates. Fig.28 In the example embodiment depicted in , the UE context modification procedure may be employed to provide the TSN bridge configuration parameters to the NG-RAN node. For example, the AMF may send a UE context modification request message to the NG-RAN node including the TSN bridge configuration parameters (TSN bridge ID, TSN system ID, etc.).

[0325] In such Fig.29 In the example embodiment depicted in , a non-UE related procedure may be adopted. In the example, the AMF may adopt the AMF configuration update procedure. In the example, the AMF configuration update procedure may be used to update the application level configuration data required for the NG-RAN node and the AMF to properly interoperate on the NG-C interface. The AMF may initiate the procedure by sending an AMF configuration update message including TSN bridge configuration parameters (TSN bridge ID), appropriate updated configuration data, etc. to the NG-RAN node. The NG-RAN node may respond with an AMF configuration update confirmation message to confirm that it has successfully updated the configuration data. If the information element is not included in the AMF configuration update message, the NG-RAN node may interpret that the corresponding configuration data has not changed and may continue to operate the NG-C interface with the existing relevant configuration data. In the example, if the PLMN support list IE is included in the AMFCONFIGURATION UPDATE message, the NG-RAN node may overwrite the list of supported PLMN identities and the corresponding list of AMF slices for each PLMN identity, and use the received values ​​for further network slice selection and AMF selection. In the example, the TSN bridge support list information element may be included in the AMF configuration update message. The TSN Bridge Support List information element may include a list of TSN bridges, TSN bridge IDs, etc. that the NG-RAN node can be associated with or that the NG-RAN node can support. The support of TSN bridges may be based on the connectivity status / condition of the NG-RAN node with the UPF of the TSN bridge. If the AMF TNL Association List IE to be added is included in the AMF CONFIGURATION UPDATE message, the NG-RAN node may (if supported) use it to establish a TNL association with the AMF. The NG-RAN node may report to the AMF in the AMF CONFIGURATION UPDATE ACKNOWLEDGE message the following situation of the successful establishment of a TNL association with the AMF: the list of successfully established TNL associations shall be included in the AMF TNL Association Setup List IE, and the list of TNL associations that failed to be established shall be included in the AMF TNL Association List IE that failed to be set.

[0326] In such Fig.29 In the example embodiment depicted in , a RAN Configuration Update procedure may be employed to update application level configuration data required for the NG-RAN node and the AMF to interoperate correctly over the NG-C interface. The NG-RAN node may initiate the procedure by sending a RAN CONFIGURATION UPDATE message to the AMF, which includes the TSN bridge configuration parameters (TSN Bridge ID) and a set of appropriately updated configuration data that has been put into operational use. The AMF may respond with a RAN CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge its successful update of the configuration data. If the information element is not included in the RAN CONFIGURATION UPDATE message, the AMF may interpret that the corresponding configuration data has not changed and may continue to operate the NG-C interface with the existing relevant configuration data.

[0327] In such Fig.29 In the example embodiment depicted in , the NG setup procedure may be used to provide the TSN bridge configuration parameters to the NG_RAN node. The NG setup procedure may be used to exchange application level data required for the NG-RAN node and the AMF to properly interoperate on the NG-C interface. This procedure may be the first NGAP procedure triggered after the TNL association has begun operation. The procedure may use non-UE associated signaling. The procedure may erase any existing application level configuration data in the two nodes and may be replaced by the received data, and may clear the AMF overload status information at the NG-RAN node. If the NG-RAN node and the AMF disagree on retaining the UE context, this procedure may re-initiate the NGAP UE-related context (if any) and may erase the related signaling connections in the two nodes. The NG-RAN node may initiate the procedure by sending an NG SETUP REQUEST message including the TSN bridge configuration parameters (TSN bridge ID), appropriate data, etc. to the AMF. The AMF may respond with an NG SETUP RESPONSE message including appropriate data.

[0328] In an example embodiment, during the handover procedure, the target NG-RAN node or NG-RAN node may receive a handover request message that may include a TSN bridge ID. If the target NG-RAN node has connectivity with the UPF of the TSN bridge, or the target NG-RAN node supports the TSN bridge with the TSN bridge ID, the target NG-RAN node may accept / adopt the handover request. In an example, the target NG-RAN node may accept the handover request based on elements of an N2 message (which may include TSN bridge configuration parameters, TSN bridge ID, etc.). The N2 message may be an NG setup request message, an initial context setup request message, an AMF configuration update message, etc. In an example, the N2 message may include a TSN capability indicator, a TSN support information element, etc. The information element may include a list of binary indicators, a flag indicating TSN bridge capability support, a vector / list of TSN bridges supported by the NG-RAN node or that may be configured at the NG-RAN node, etc.

[0329] In an example embodiment, during a handover procedure, a target RAN node, a target NG-RAN node, etc. for handover may be selected. The target NG-RAN node may receive a handover request from a source NG-RAN node. The source NG-RAN node may select the target NG-RAN node from one or more candidates and based on a measurement report received from a wireless device. In an example, the source NG-RAN node may receive an Xn setup request message from a neighboring NG-RAN node (e.g., a target NG-RAN node). In an example, the Xn setup request may include TSN bridge configuration parameters, TSN bridge ID, etc. The source NG-RAN node may send an Xn setup response message, which may include TSN bridge configuration parameters, TSN bridge ID, etc. In an example, during the handover procedure, the source NG-RAN node may select a target NG-RAN node based on elements of the Xn setup request / response message. For example, the source NG-RAN node may select a target NG-RAN node that supports a TSN bridge with a TSN bridge ID. In an example, an NG-RAN node configuration update procedure may be employed. For example, the NG-RAN nodes may exchange configuration data and parameters, such as TSN bridge configuration parameters, TSN bridge ID, etc. During the handover procedure, the NG-RAN node may select a target NG-RAN node based on elements of the NG-RAN node configuration update message / request (e.g., TSN bridge ID) and the NG-RAN node configuration update confirmation. The provision and exchange of TSN bridge configuration parameters may improve signaling performance during the handover procedure, where the source NG-RAN node may select a target NG-RAN node that may provide services (may have connectivity) to the UPF of the TSN bridge and thereby avoid handover failure or rejection by the target NG-RAN node. For example, the source NG-RAN node may receive an Xn setup message or an NG-RAN node configuration update message from a first NG-RAN node including a first TSN bridge ID, and may receive an Xn setup message or an NG-RAN configuration update message from a second NG-RAN node including a second TSN bridge ID. If the NG-RAN node determines to handover a wireless device of a TSN bridge having a first TSN bridge ID, the NG-RAN may select the first NG-RAN node.

[0330] In such Fig.30 and Fig.32In the example embodiment depicted in , an Xn setup procedure or an NG-RAN node configuration update procedure may be employed. When the NG-RAN node receives (e.g., via an N2 message, etc.) TSN bridge configuration parameters, TSN bridge IDs, etc., the NG-RAN node may employ the Xn setup procedure or the NG-RAN node configuration update procedure to update neighboring NG-RAN nodes related to TSN bridge capability support and TSN bridge IDs that the NG-RAN node may support. In the example, the NG-RAN node may employ the Xn setup procedure or the NG-RAN node configuration update procedure to exchange TSN configuration parameters, TSN bridge configuration parameters, TSN capability support, TSN bridge IDs, etc. with neighboring NG-RAN nodes.

[0331] In such Fig.30 and Fig.32In the example embodiment of the present invention, an Xn setup procedure may be used to exchange application-level configuration data required for two NG-RAN nodes to properly interoperate over the Xn-C interface. The procedure may employ non-UE-associated signaling. The NG-RAN node 1 may initiate the procedure by sending an XN SETUP REQUEST message to the candidate NG-RAN node 2. The candidate NG-RAN node 2 may reply with an XN SETUP RESPONSE message. In an example, the XN SETUP REQUEST message may include TSN bridge configuration parameters, TSN bridge IDs that the NG-RAN node 1 may support, TSN capability support indications, etc. In an example, the XN SETUP RESPONSE message may include TSN bridge configuration parameters, TSN bridge IDs that the NG-RAN node 2 may support, TSN capability support indications, etc. In an example, elements of the XN setup request message and / or the Xn setup response message may be employed during a handover procedure, wherein the target NG-RAN node (e.g., NG-RAN node 1 or NG-RAN node 2) may determine to accept, adopt, or reject the handover request based on whether it supports TSN bridge capabilities or TSN bridge features, etc. In an example, elements of the XN SETUP REQUEST message and / or the XN SETUP RESPONSE message may be employed during a handover procedure, where the target NG-RAN node (e.g., NG-RAN node 1 or NG-RAN node 2) may determine to accept, adopt, or reject the handover request based on elements of the TSN bridge configuration parameters, TSN bridge IDs supported or owned by the NG-RAN node. If the supplementary uplink is configured at the NG-RAN node 1, the NG-RAN node 1 may include the SUL information IE and the supported SUL band list IE of each served cell configured with the supplementary uplink in the XN SETUP REQUEST message. If the supplementary uplink is configured at the NG-RAN node 2, the candidate NG-RAN node 2 may include the SUL information IE and the supported SUL band list IE of each served cell configured with the supplementary uplink in the XN SETUP RESPONSE message. If the NG-RAN node 1 is an ng-eNB, it may include the protected E-UTRA resource indication IE in the XN SETUP REQUEST. If the XN SETUP REQUEST sent by the ng-eNB includes the Protected E-UTRA Resource Indication IE, the receiving gNB may take this into account for cell level resource coordination with the ng-eNB. The gNB may consider the received Protected E-UTRA Resource Indication IE content as valid until a new update of the IE is received by the same ng-eNB.The protected resource pattern shown in the protected E-UTRA resource indication IE is invalid in the subframe indicated by the reserved subframe IE and in the non-control region of the MBSFN subframe. The size of the control region of the MBSFN subframe may be indicated in the protected E-UTRA resource indication IE. In the case where the network shares multiple cell IDs broadcasted using shared Xn-C signaling, the XN SETUP REQUEST message and the XN SETUP REQUESTACKNOWLEDGE message may include an interface instance indication IE to identify the corresponding interface instance.

[0332] In such Fig.30 and Fig.32In the example embodiment depicted in , the NG-RAN node configuration update procedure may be used to update application level configuration data required for two NG-RAN nodes to properly interoperate over the Xn-C interface. The procedure may employ non-UE associated signaling. The NG-RAN node 1 may initiate the procedure by sending an NG-RAN NODE CONFIGURATION UPDATE message to the peer NG-RAN node 2. In the example, the NG-RAN NODE CONFIGURATION UPDATE message may include TSN bridge configuration parameters, TSN bridge IDs that the NG-RAN node 1 may support, TSN capability support indications, etc. In the example, the NG-RAN NODE CONFIGURATION UPDATE confirmation message may include TSN bridge configuration parameters, TSN bridge IDs that the NG-RAN node 2 may support, TSN capability support indications, etc. If supplementary uplink is configured at the NG-RAN node 1, the NG-RAN node 1 may include in the NG-RAN NODE CONFIGURATION UPDATE message the SUL information IE and the supported SUL frequency band list IE for each cell added in the served NR cells to be added IE and the served NR cells to be modified IE. If supplementary uplink is configured at the NG-RAN node 2, the NG-RAN node 2 may include the SUL information IE and supported SUL band list IE for each cell added to the served NR cell IE (if any) in the NG-RAN NODECONFIGURATION UPDATE ACKNOWLEDGE message. If the TAI support list IE is included in the NG-RAN NODECONFIGURATION UPDATE message, the receiving node may replace the previously provided TAI support list IE with the received TAI support list IE. If the cell assistance information NR IE is present, the NG-RAN node 2 may use it to generate the served NR cell IE and include the list in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message. Upon receiving the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node 2 may update the information of NG-RAN node 1 as follows: If the network shares multiple cell IDs broadcast using shared Xn-C signaling, the NG-RAN NODE CONFIGURATION UPDATE message and the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message may include an interface instance indication IE to identify the corresponding interface instance.The provision of TSN bridge information (such as TSN bridge configuration parameters, TSN bridge ID, etc.) can improve the signaling performance of the 3GPP system during the handover procedure. The NG-RAN node can use the TSN bridge information to determine whether to adopt / accept the handover of the wireless device for the TSN bridge based on the TSN bridge information. For example, the first target NG-RAN node can receive the first TSN bridge ID via the N2 message, and the second NG-RAN node can receive the second TSN bridge ID. When the first NG-RAN node receives the handover request including the second TSN bridge ID, the first NG-RAN node can reject the handover request and send a handover failure message. When the first NG-RAN node receives the handover request including the first TSN bridge ID, the first NG-RAN node can accept the handover request. In an example, elements of a RAN NODE CONFIGURATION UPDATE and / or a RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message may be employed during a handover procedure, wherein a target NG-RAN node (e.g., NG-RAN node 1 or NG-RAN node 2) may determine to accept, adopt, or reject a handover request based on whether it supports TSN bridge capabilities or TSN bridge features, etc. In an example, elements of a RAN NODE CONFIGURATION UPDATE and / or a RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message may be employed during a handover procedure, wherein a target NG-RAN node (e.g., NG-RAN node 1 or NG-RAN node 2) may determine to accept, adopt, or reject a handover request based on elements of a TSN bridge configuration parameter, a TSN bridge ID that the NG-RAN node supports or belongs to.

[0333] In such Fig.32 In the example embodiment depicted in , the XN setup request message and / or the NG-RAN node configuration update message may include an area of ​​interest information element or field. The area of ​​interest for 3GPP access may include a tracking area list, a cell identifier associated with a TSN system or a TSN bridge, a CAG list associated with a TSN bridge or a TSN system, an NG-RAN node identifier, a presence reporting area ID, and one or more elements of the presence reporting area, such as a TA and / or NG-RAN node and / or cell identifier, a LADN DNN, etc.

[0334] In such Fig.31In the example embodiment depicted in , an S-NG-RAN node addition preparation procedure may be employed to request the S-NG-RAN node to allocate resources for dual connectivity operation of a UE of a TSN bridge. The procedure may employ UE-associated signaling. The M-NG-RAN node may initiate the procedure by sending an S-NODE ADDITION REQUEST message to the S-NG-RAN node. The S-NODEADDITION REQUEST message may include a TSN bridge capability support indication. The S-NODE ADDITION REQUEST message may include TSN bridge configuration parameters, TSN bridge ID, etc. When the M-NG-RAN node sends the S-NODE ADDITION REQUEST message, it may start a timer TXnDCprep. Allocating resources according to the value of the allocation and retention priority IE included in the QoS flow level QoS parameters IE of each QoS flow may follow the principles specified for the PDU session resource setting procedure. The S-NG-RAN node may select an encryption algorithm based on the information in the UE security capability IE and the locally configured priority list of the AS encryption algorithm, and may apply the key indicated in the S-NG-RAN node security key IE. If the S-NODEADDITION REQUEST message contains a mobility restriction list IE, the S-NG-RAN node (if supported) can store the information and use it to select an appropriate SCG. In an example, the mobility restriction list may include radio access technology (RAT) restrictions, prohibited areas, service area restrictions, core network type restrictions, and closed access group information, etc. The mobility restrictions may include TSN system restrictions, which include network slices for TSN systems, network slices for TSN bridges, network slice-aware restrictions for DNNs associated with TSN systems or TSN bridges, etc. In an example, the CAG restrictions may include a CAG list for the TSN system. For example, the CAG id may be mapped to a TSN system ID, a TSN bridge, a TSN bridge ID, etc. If the S-NODE ADDITION REQUEST message contains a QoS flow mapping indication IE, the S-NG-RAN node may consider only uplink or downlink QoS flows to be mapped to DRBs. The S-NG-RAN node may report the results of all requested PDU session resources to the M-NG-RAN node in the S-NODE ADDITION REQUEST ACKNOWLEDGE message in the following manner: The list of successfully established PDU session resources may be included in the Adopted PDU Session Resources List to be Added IE. The list of PDU session resources that failed to be established may be included in the Not Adopted PDU Session Resources List IE.Upon receiving the S-NODE ADDITION REQUEST ACKNOWLEDGE message, the M-NG-RAN node may stop the timer TXnDCprep. If the S-NODE ADDITION REQUESTACKNOWLEDGE message contains the MR-DC Resource Coordination Information IE, the M-NG-RAN node may use it for the purpose of resource coordination with the S-NG-RAN node. The M-NG-RAN node may consider the value of the received UL Coordination Information IE to be valid until a new update of the IE for the same UE is received. The M-NG-RAN node may consider the value of the received DL Coordination Information IE to be valid until a new update of the IE for the same UE is received. If the E-UTRA Coordination Assistance Information IE or the NR Coordination Assistance Information IE is included in the MR-DC Resource Coordination Information IE, the M-NG-RAN node (if supported) may use this information to determine further coordination of resource utilization between the M-NG-RAN node and the S-NG-RAN node. The S-NG-RAN node may include a PDCP SN Length IE in the S-NODEADDITION REQUEST ACKNOWLEDGE message for each bearer in the DRB List to be configured IE to indicate the PDCP SN length for the DRB. If the S-NG-RAN node UE XnAP ID IE is included in the S-NODE ADDITION REQUEST message, the S-NG-RAN node (if supported) may store this information. If the S-NODE ADDITION REQUEST message contains a PDCP SN Length IE, the S-NG-RAN node (if supported) may store this information and use it for lower layer configuration of the relevant MN terminated bearers. If the S-NODE ADDITION REQUEST ACKNOWLEDGE message contains an RRC Configuration Indication IE, the M-NG-RAN node may consider the appropriate configuration (full or incremental) to be applied by the S-NG-RAN node. If the S-NODE ADDITION REQUEST message contains the S-NG-RAN node maximum integrity protected data rate uplink IE or the S-NG-RAN node maximum integrity protected data rate downlink IE, the S-NG-RAN node may use the received information when performing maximum integrity protected data rate for the UE. If location information at the S-NODE report IE is included in the S-NODE ADDITION REQUEST, the S-NG-RAN node (if supported) may start providing information about the current location of the UE.If the location information at the S-NODE IE is included in the S-NODE ADDITION REQUEST ACKNOWLEDGE, the M-NG-RAN node may transmit the included information towards the AMF. If the S-NG-RAN node adopts at least one PDU session resource, the S-NG-RAN node may start the timer TXnDCoverall when sending the S-NODEADDITION REQUEST ACKNOWLEDGE message to the M-NG-RAN node. The reception of the S-NODE RECONFIGURATION COMPLETE message may stop the timer TXnDCoverall. Upon receiving the S-NODE ADDITION REQUEST message containing the Required Activity Notification Level IE, the S-NG-RAN node (if supported) may use this information to decide whether to trigger a subsequent activation notification procedure based on the requested notification level.

[0335] In such Fig.33In the example depicted in , a handover preparation procedure may be employed to establish the necessary resources for the incoming handover in the NG-RAN node. The procedure may employ UE-associated signaling. The source NG-RAN node may initiate the procedure by sending a HANDOVER REQUEST message to the target NG-RAN node. When the source NG-RAN node sends the HANDOVER REQUEST message, it may start a timer TXnRELOCprep. In an example, the handover request message may include an indication that the handover is for a UE of a TSN bridge. The indication may include information elements indicating TSN capability support, TSN bridge function support, etc. In an example, the handover request message may include TSN bridge configuration parameters, TSN bridge ID, etc. When the target NG-RAN node receives the handover request message, the target NG-RAN node may accept, adopt, or reject the handover request. The receipt of the handover request may be based on an element of the handover request message. For example, when the target NG-RAN node receives the TSN bridge ID via an N2 message and is configured for a TSN bridge with a TSN bridge ID, the target NG-RAN node may accept the handover request. In an example, if the target NG-RAN node is not configured for a TSN system, a TSN bridge, or when the target NG-RAN node is configured for a TSN bridge with a different TSN bridge ID, the target NG-RAN node may reject the request and send a handover preparation failure message. For each E-RAB ID IE included in the QoS Flow List to be Set IE in the HANDOVERREQUEST message, the target NG-RAN node (if supported) may store the content of the IE in the UE context and use the content for subsequent inter-system handovers. If the Masked IMEISV IE is included in the HANDOVER REQUEST message, the target NG-RAN node (if supported) may use it to determine the characteristics of the UE for subsequent processing. Upon receiving the HANDOVER REQUEST message, the target NG-RAN node may prepare the configuration of the AS security relationship between the UE and the target NG-RAN node by using the information in the UE Security Capability IE and the AS Security Information IE in the UE Context Information IE. The target NG-RAN node may report the result of the successful establishment of all requested PDU session resources in a HANDOVER REQUESTACKNOWLEDGE message. When the target NG-RAN node reports that the PDU session resources were not successfully established, the cause value may be precise enough to enable the source NG-RAN node to know the reason for the unsuccessful establishment. In an example, the cause value may be an unsupported TSN, an unsupported TSN bridge ID, etc.For each PDU Session, if the PDU Session Aggregate Maximum Bit Rate IE is included in the PDU Session Resources List to be Set IE included in the HANDOVER REQUEST message, the target NG-RAN node may store the received PDU Session Aggregate Maximum Bit Rate in the UE context and use it when performing traffic policing of non-GBR QoS flows for the UE concerned. For each QoS flow for which the source NG-RAN node proposes / instructs to perform downlink data forwarding, the source NG-RAN node may include in the PDU Session Resources List to be Set IE in the HANDOVER REQUEST message the DL Forwarding IE set to "Proposed DL Forwarding" in the Data Forwarding and Offload Information from the Source NG-RAN Node IE. For each PDU Session for which the target NG-RAN node decides to adopt data forwarding for at least one QoS flow, the target NG-RAN node may include in the Adopted PDU Session Resources Information IE included in the Adopted PDU Session Resources List IE in the HANDOVER REQUESTACKNOWLEDGE message the PDU Session Level DL Data Forwarding GTP-U Tunnel Endpoint IE in the Data Forwarding Information from the Target NG-RAN Node IE. For each QoS flow for which the source NG-RAN node has not received a SDAP end marker packet, if QoS flow remapping occurs before handover, the source NG-RAN node may include the UL forwarding IE in the data forwarding and offloading information from the source NG-RAN node IE in the HANDOVER REQUES message, and if the target NG-RAN node decides to adopt uplink data forwarding for at least one QoS flow, the target NG-RAN node may include the PDU session level UL data forwarding UP TNL information IE in the data forwarding information from the target NG-RAN node IE in the adopted PDU session resource item IE included in the adopted PDU session resource list IE in the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts uplink data forwarding. For each PDU session resource successfully set up at the target NG-RAN, the target NG-RAN node may allocate resources for the additional Xn-U PDU session resource GTP-U tunnels indicated in the secondary data forwarding information from the target NG-RAN node list IE. For each DRB for which the source NG-RAN node proposes to perform downlink data forwarding, the source NG-RAN node may include the DRB ID IE and the mapped QoS Flow List IE within the Source DRB to QoS Flow Mapping List IE contained in the PDU Session Resource List IE to be set up in the HANDOVER REQUEST message.The source NG-RAN node may include a QoS Flow Mapping Indication IE in the Source DRB to QoS Flow Mapping List IE to indicate that only uplink or downlink QoS flows are mapped to the DRB. If the target NG-RAN node decides to use the same DRB configuration and map the same QoS flows as the source NG-RAN node, the target NG-RAN node may include a DL Forwarding GTP Tunnel Endpoint IE in the Data Forwarding Response DRB List IE in the HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the downlink data forwarding proposed for this DRB. If the HANDOVER REQUEST ACKNOWLEDGE message contains a UL Forwarding GTP Tunnel Endpoint IE for a given DRB in the Data Forwarding Response DRB List IE in the Data Forwarding Information from the Target NG-RAN Node IE in the Adopted PDU Session Resource List IE, and the source NG-RAN node accepts the data forwarding proposed by the target NG-RAN node, the source NG-RAN node may perform uplink data forwarding for the DRB. If the HANDOVER REQUEST includes PDU session resources for PDU sessions associated with S-NSSAI not supported by the target NG-RAN, the target NG-RAN may reject such PDU session resources. In this case, and if at least one PDU session resource item to be set IE is adopted, the target NG-RAN may send a HANDOVER REQUEST ACKNOWLEDGE message including an Unadopted PDU Session Resource List IE listing the corresponding PDU sessions rejected at the target NG-RAN.

[0336] In such Fig.33 In an example embodiment, if the wireless device (UE of a TSN bridge), the target NG-RAN node may receive a handover request message including a PDU session ID. The NG-RAN node may map or determine that the PDU session is associated with a TSN bridge with a TSN bridge ID. The target NG-RAN node may determine to accept or reject the handover based on the determination and an element of the N2 message (e.g., TSN bridge ID). In an example, the target NG-RAN node may determine the TSN bridge ID from the PDU session ID via the AMF.

[0337] In such Fig.34In the example embodiment depicted in , when the AMF remains unchanged and the SMF decides / determines to keep the existing UPF, an Xn-based handover procedure can be used to hand over the UE from the source NG-RAN to the target NG-RAN using Xn. If the PLMN has configured the secondary RAT usage report, the source NG-RAN node may provide the AMF with a RAN usage data report (N2 SM information (secondary RAT usage data), handover flag, source to target transparent container) during the handover execution phase. The source NG-RAN node may provide this report when the target NG-RAN has confirmed the handover over the Xn interface. The handover flag may indicate to the AMF that it should buffer the N2 SM information containing the usage data report before forwarding it. If the source NG RAN and the target NG RAN support RACS, the source to target transparent container may include the UE radio capability ID of the UE instead of the UE radio access capabilities. The target NG-RAN may send an N2 path switch request to the AMF (e.g., including TSN bridge ID, TSN bridge configuration parameters, a list of PDU sessions to be switched using N2 SM information, a list of PDU sessions that failed to be established due to a failure reason given in the N2 SM information element, UE location information, etc.). The target NG-RAN may send an N2 path switch request message to the AMF to notify that the UE has moved to a new target cell, and may provide TSN bridge ID, TSN bridge configuration parameters, a list of PDU sessions to be switched, etc. In the example, AN tunnel information for each PDU session to be switched may be included in the N2 SM information. If redundant transmission is performed for one or more QoS flows in a PDU session, two AN tunnel information may be provided by the target NG-RAN, and the target NG-RAN may indicate to the SMF or AMF to use one of the AN tunnel information as a redundant tunnel for the PDU session. If the target NG-RAN provides one AN tunnel information for a PDU session, the SMF may release these QoS flows by triggering a PDU session modification procedure after the handover procedure. The selected PLMN ID (or PLMN ID and NID, etc.) may be included in the message. The target NG-RAN may include the PDU session in the rejected PDU session list in the following cases: if the target NG-RAN does not accept any QoS flow for the PDU session; or if the corresponding network slice is not supported in the target NG-RAN; or the corresponding TSN bridge ID is not supported in the target NG-RAN node; or when the NG-RAN is unable to set the user plane resources to have the required value to satisfy the user plane security enforcement, the NG-RAN refuses to establish user plane resources for the PDU session. If the NG-RAN is unable to set the user plane resources to have the preferred value to satisfy the user plane security enforcement, the NG-RAN may establish user plane resources for the PDU session and may include the PDU session in the modified PDU session list.The rejected PDU Session may include an indication whether the PDU Session is rejected because User Plane Security enforcement is not supported in the target NG-RAN. Depending on the type of target cell, the target NG-RAN may include appropriate information in this message. For the PDU Session to be handed over to the target NG-RAN, the N2 Path Switch Request message may include a list of accepted QoS Flows.

[0338] The AMF may send a Nsmf_PDUSession_UpdateSMContext request to the SMF (e.g., including: TSN bridge ID, TSN bridge configuration parameters, N2 SM information received from T-RAN and N2 SM information received from the source NG-RAN (secondary RAT usage data), UE location information, UE presence in the LADN service area, etc.). The AMF may send the N2 SM information by calling the Nsmf_PDUSession_UpdateSMContext request service operation for each PDU session in the list of PDU sessions received in the N2 path switch request. The Nsmf_PDUSession_UpdateSMContext request may include an indication that the PDU session is to be switched (together with information about N3 addressing usage and the QoS flow delivered) or an indication that the PDU session will be rejected (together with the reason for rejection). For PDU sessions to be switched to the target NG-RAN, upon receiving the Nsmf_PDUSession_UpdateSMContext request, the SMF may determine whether the existing UPF can continue to provide services to the UE of the TSN bridge. If the existing UPF cannot continue to provide services to the UE, UPF reallocation may be performed. In an example, the determination performed by the SMF may be based on a mapping of a TSN bridge ID or a PDU session to a bridge ID and determining whether an available UPF of the TSN bridge has connectivity with the target NG-RAN node. If a PDU session is rejected by the target NG-RAN, where it is indicated that the PDU session is rejected because user plane security enforcement is not supported in the target NG-RAN and the user plane enforcement policy indicates "required", the SMF may trigger the release of this PDU session. In all other cases of PDU session rejection, the SMF may decide whether to release the PDU session or deactivate the UP connection for this PDU session. If some QoS flows of the PDU session are not accepted by the target NG-RAN, the SMF may initiate a PDU session modification procedure to remove the unaccepted QoS flows from the PDU session after completing the handover procedure. For PDU sessions that do not have an active N3 UP connection before the handover procedure, the SMF may remain inactive after the handover procedure. If the UE moves into a non-allowed area, the AMF may notify each NF consumer (e.g. SMF of an established PDU session) that has subscribed to UE reachability events via Namf_EventExposure_Notify that the UE is reachable only for regulatory priority services. If this PDU session is not for emergency services, the SMF may deactivate the PDU session.

[0339] In an example, the SMF may send an N4 session modification request (e.g., including TSN bridge ID, TSN bridge configuration parameters, AN tunnel information, CN tunnel information, etc.) to the UPF. In an example, the SMF may determine an identifier of a port (e.g., TSN port) of the UPF to be reconfigured. The N$session modification message may include a bridge ID, a port ID associated with a PDU session, etc. For a PDU session modified by the target NG-RAN, the SMF may send an N4 session modification request message to the UPF. The SMF may notify the UPF that initiated the data notification to discard the downlink data of the PDU session and / or not provide further data notification messages. Depending on the network deployment, the CN tunnel information for the UPF connected to the target NG-RAN and the UPF connected to the source NG-RAN may be different, for example, because the source and target NG-RAN are in different IP domains. If the CN tunnel information of the UPF (on N3) needs to be reallocated and the CN tunnel information is allocated by the SMF, the SMF may provide the CN tunnel information (on N3) to the UPF. If redundant transmission is performed for one or more QoS flows of the PDU session, two CN tunnel information are provided to the UPF. When two CN tunnel information are provided, the SMF may indicate to the UPF that one CN tunnel information is used as a redundant tunnel for the PDU session. The UPF may send an N4 session modification response (e.g., including CN tunnel information) to the SMF. For the switched PDU session, the UPF may return an N4 session modification response message to the SMF after the requested PDU session is switched. The tunnel identifier for the UL service is included only for PDU sessions whose user plane resources are not being released and only when the UPF allocates CN tunnel information and needs to allocate different CN tunnel information. In the example, in order to assist the reordering function in the target NG-RAN, the UPF may send one or more "end marker" packets for each N3 tunnel on the old path immediately after switching the path. The UPF may start sending downlink packets to the target NG-RAN.

[0340] In the example, the SMF may send a Nsmf_PDUSession_UpdateSMContext response (including CN tunnel information) to the AMF. The SMF may send a Nsmf_PDUSession_UpdateSMContext response (CN tunnel information) to the AMF for the PDU sessions that have been successfully switched. The CN tunnel information of the UPF sent to the AMF may be used to set up the N3 tunnel. The AMF may send an N2 Path Switch Request Ack (including N2 SM information, failed PDU sessions, UE radio capability ID, etc.) to the NG-RAN. Once the Nsmf_PDUSession_UpdateSMContext responses are received from all SMFs, the AMF may aggregate the received CN tunnel information and may send this aggregated information as part of the N2 SM information together with the failed PDU sessions in the N2 Path Switch Request Ack to the target NG-RAN. If none of the requested PDU sessions are successfully switched, the AMF may send an N2 Path Switch Request Failure message to the target NG-RAN. If the UE radio capability ID is included in the N2 Path Switch Request Ack message, the target NG-RAN may request the AMF to provide the UE radio capability set corresponding to the UE radio capability ID to the target NG-RAN when there is no corresponding UE radio capability set for the UE radio capability ID at the target NR-RAN. The target NG-RAN may confirm the handover success by sending a Release Resources message to the source NG-RAN and may trigger the release of resources with the source NG-RAN.

[0341] In such Fig.34 and Fig.35 In the example embodiment of , the SMF may determine that the UPF may not provide services to the UE via the target NG-RAN node. The SMF may reallocate the UPF. The SMF may select a UPF that supports TSN functionality, TSN converter functionality, etc. The SMF may select the UPF via the NRF by adopting the Nrf discovery and selection service. The SMF may send a query to the NRF indicating a request to discover or select a UPF that supports TSN functionality, a TSN bridge with a TSN bridge ID, etc. The NRF may send a response message to the SMF having an identifier or address of a UPF that is part of the TSN bridge ID or that supports the TSN bridge functionality. The SMF may perform an N4 session establishment procedure or modification procedure, and may configure the UPF of the TSN bridge. After reconfiguring the TSN bridge, the SMF may report the bridge configuration data / parameters to the CNC via the NEF, AF, etc.

[0342] In an example, the bridge configuration may cause a 5GS bridge (TSN bridge) capability reporting procedure such as Fig.36As depicted in . When the TSN bridge configuration has changed, a new TSN bridge has been created, etc., the TSN capability report of the 5GS TSN bridge can be adopted. The identities of the 5GS virtual bridge and UPF ports, TSN bridge configuration parameters, etc. can be pre-configured based on the deployment on the UPF, and can be registered with the SMF. The SMF can report the information to the AF (directly or via the NEF). The UPF can assign an identity to the UE virtual port, and can send the virtual port identity with the corresponding 5GS virtual bridge identity (for example, when the UE establishes a PDU session) to the SMF. The virtual port identity can be unique in the 5G virtual bridge (TSN bridge). The SMF can register the virtual port to the 5GS virtual bridge, where its identity is registered to the AF. The SMF can collect the topology and delay time information of the 5GS virtual bridge. The SMF can report the topology and delay time information to the AF. The AF can register the 5GS virtual bridge information to the CNC or update it.

[0343] In such Fig.37 In the example depicted in , during the TSN bridge capability reporting procedure, the SMF may send a NAS message to the UE (e.g., when establishing a PDU session) to configure a virtual port (TSN port) on the UE. The SMF, PCF, NEF, or AF may send the TSN virtual port identity of the UE to the AMF, and the AMF may send the NAS message to the UE of the TSN bridge during the registration procedure of the UE with the 3GPP 5G system. When configuring the TSN bridge, the SMF may send TSN bridge configuration parameters, TSN bridge ID, etc. to the AMF. The AMF may provide the TSN bridge configuration parameters, bridge ID, etc. to the RAN node or NG-RAN node via the N2 interface by adopting an N2 message. In the example, the TSN bridge configuration parameters, TSN bridge ID, etc. may be provided to the AMF from the PCF, NEF, and / or AF. When receiving a configuration update from the SMF (when reconfiguring the TSN bridge), the PCF, NEF, or AF may provide the TSN bridge configuration parameters, TSN bridge ID, etc. to the AMF.

[0344] In such Fig.38In the example embodiment depicted in , a TSN bridge information reporting procedure may be adopted. The identities of the 5GS bridge and the UPF / NW-TT ports may be pre-configured based on the deployment on the UPF. The identities of the 5GS bridge and the UPF / NW-TT ports may be determined by the SMF and configured based on the deployment on the UPF. In the example, the UE of the TSN bridge may perform a PDU session establishment procedure. The PDU session establishment procedure may be for time-sensitive communications via the TSN bridge. During the PDU session establishment procedure, the SMF may select a UPF that supports the functions of TSN, TSC, TSN converter / adapter, etc. for the PDU session. During the PDU session establishment procedure, the SMF may receive the UE-DS-TT residence time, DS-TT MAC address for the PDU session from the UE in the PDU session establishment request, and may receive the allocated port number for DS-TT, the port number for NW-TT, and the bridge ID in the N4 session establishment response message. The UPF may allocate a port number for the DS-TT, and may decide / determine the port number and bridge ID of the NW-TT after receiving the N4 session establishment request message. The SMF may construct the received information into 5GS bridge information, TSN bridge information, TSN bridge configuration parameters, etc. The SMF may send the 5GS bridge information to the AF via the PCF to establish / modify the 5GS TSN bridge. The AF may store the binding relationship between the 5GS TSN bridge ID, the MAC address of the DS-TT, the DS-TT port number, and the NW-TT port number of the 5GS TSN bridge for future configuration. The UE / DS-TT may send a port management information container to the SMF in a PDU session modification request. The port management information container may include Tx propagation delay, scale granularity and gate control information (AdminBaseTime, AdminControlList, AdminCycleTime, and AdminControlListLength), LLDP configuration (such as chassis ID), information about discovered neighbors, etc. The SMF may (transparently) transmit the received port management information container to the AF via the PCF. The UPF / NW-TT may send its port management information container to the SMF via the N4 session report. The SMF may (transparently) transmit the received port management information container to the AF via the PCF. The AF may maintain the received 5GSTSN bridge information and may send it to the CNC to register a new TSN bridge or update an existing TSN bridge.

[0345] In such Fig.38In the example in , during TSN bridge information reporting, UPF may send TSN bridge configuration parameters and / or TSN bridge ID to SMF. SMF may transmit TSN bridge configuration parameters and / or TSN bridge ID to AMF. AMF may provide TSN bridge configuration parameters and / or TSN bridge ID to NG-RAN node via N2 message.

[0346] In such Fig.39 In the example embodiment depicted in FIG. 1 , when configuring, reconfiguring, reporting information, etc. of a TSN bridge (e.g., Fig.36 , Fig.37 and Fig.38 ), TSN bridge configuration parameters, TSN bridge ID, port ID, etc. may be provided to the OAM (OA&M) network element. The OAM may receive TSN information from the UPF, PCF, NEF, AF, etc. In an example, the OAM network element may provide the TSN bridge configuration parameters, TSN bridge ID, port ID, etc. to the AMF or NG-RAN node. In response to receiving the information from the OAM, the NG-RAN node may perform an NG-RAN configuration update or Xn setup procedure with a neighboring NG-RAN node or base station.

[0347] In such Fig.40 In the example embodiment depicted in FIG, network controlled mobility can be applied to UEs in RRC_CONNECTED and can be categorized into two types of mobility: cell level mobility and beam level mobility. Cell level mobility may require triggering explicit RRC signaling, such as handover. For inter-gNB handover, the signaling procedure may include Fig.40 The source gNB may initiate a handover and issue a handover request over the Xn interface. The handover request may include a TSN bridge ID. The target gNB may determine (e.g., via the AMF) whether the handover request of the UE for the TSN bridge ID can be adopted). In an example, the S-gNB may send a list of candidate target gNBs and TSN bridge IDs to the AMF. The AMF may determine a target gNB that supports TSN bridges and respond with an identifier of the target gNB. The target gNB may perform adoption control and provide an RRC configuration as part of the handover confirmation. The source gNB may provide the RRC configuration to the UE in the handover command. The handover command message may include at least a cell ID and information required to access the target cell so that the UE can access the target cell. For certain cases, information required for contention-based and contention-free random access may be included in the handover command message. Access information for the target cell may include beam-specific information (if any). The UE may transfer / move the RRC connection to the target gNB and may reply with a handover complete message.

[0348] In such Fig.41 and Fig.42 In the example embodiment depicted in , the control plane processing of the handover procedure is described. An intra-NRRAN handover may perform the preparation and execution phases of the handover procedure performed without involving the 5GC, for example, by exchanging preparation messages directly between gNBs. The release of resources at the source gNB during the handover completion phase may be triggered by the target gNB. Example Fig.41 and Fig.42A handover scenario is depicted where neither the AMF nor the UPF is changed. The UE context within the source gNB may include information related to roaming and access restrictions provided at connection establishment or last TA update. The source gNB may configure the UE measurement procedures and UE reporting based on the measurement configuration. The source gNB may determine / decide to handover the UE based on the measurement reports and radio resource management (RRM) information. The source gNB may issue a handover request message with the information necessary to prepare for the handover at the target side (e.g., may include TSN bridge configuration parameters, TSN bridge ID, etc.) to the target gNB delivering the RRC transparent container. The information may include at least: target cell ID; KgNB*; C-RNTI of the UE in the source gNB; RRM configuration including UE inactive time; basic AS configuration including antenna information and DL carrier frequency; mapping rules of the current QoS flow to DRB applied to the UE; SIB1 from the source gNB; UE capabilities for different RATs; PDU session related information, and the information may include measurement information reported by the UE including beam related information (if available). PDU session related information includes slice information (if supported) and QoS flow level QoS profile. After issuing the Handover Request, the Source gNB shall not reconfigure the UE, including performing Reflective QoS flows to DRB mapping. Adoption control may be performed by the Target gNB. If slice information is sent to the Target gNB, Slice-aware Adoption control may be performed. If a PDU Session is associated with an unsupported slice, the Target gNB shall reject such PDU Session. Adoption control may be performed based on elements of the Handover Request message (e.g., TSN Bridge Configuration Parameters, TSN Bridge ID) and elements of the N2 message received from the AMF (e.g., TSN Bridge Configuration Parameters provided via NG Setup, AMF Configuration, etc.). The Target gNB may prepare for the Handover using L1 / L2 and send a HANDOVER REQUEST ACKNOWLEDGE to the Source gNB, which may include a transparent container to be sent as an RRC message to the UE to perform the Handover. The Source gNB may trigger the Uu Handover by sending an RRC Reconfiguration message to the UE, which may include information required to access the target cell, e.g., at least the target cell ID, the new C-RNTI, the Target gNB security algorithm identifier for the selected security algorithm, etc. It may also include a set of dedicated RACH resources, association between RACH resources and SSBs, association between RACH resources and UE-specific CSI-RS configurations, common RACH resources, and system information of the target cell. The source gNB may send an SN STATUS TRANSFER message to the target gNB. The UE may synchronize to the target cell and may complete the RRC handover procedure by sending an RRCReconfigurationComplete message to the target gNB.The target gNB may send a PATH SWITCH REQUEST message to the AMF to trigger the 5GC to switch the DL data path towards the target gNB and establish an NG-C interface instance towards the target gNB. The PATH SWITCH REQUEST message may include TSN bridge configuration parameters, TSN bridge ID, etc. The 5GC may switch the DL data path towards the target gNB. The UPF may send one or more "end marker" packets on the old path per PDU session / tunnel to the source gNB and may then release any U-plane / TL resources towards the source gNB. The AMF may acknowledge the PATH SWITCH REQUEST message with a PATH SWITCH REQUEST ACKNOWLEDGE message. On receiving the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB may send UE CONTEXT RELEASE to inform the source gNB of the handover success. The source gNB may release the radio and C-plane related resources associated with the UE context. Any ongoing data forwarding may continue.

[0349] In such Fig.43 and Fig.45In the example embodiment depicted in , the source NG-RAN may determine / decide to initiate an N2-based handover to the target NG-RAN. This may be triggered, for example, due to new radio conditions or load balancing if there is no Xn connectivity with the target NG-RAN, an error indication from the target NG-RAN after an unsuccessful Xn-based handover (i.e., no IP connectivity between the T-RAN and the S-UPF), or based on dynamic information learned by the S-RAN. The availability of the direct forwarding path is determined in the source NG-RAN and indicated to the SMF. If IP connectivity between the source NG-RAN and the target NG-RAN is available and a security association between them is in place, the direct forwarding path is available. In the example, an N2-based handover may be performed. The S-RAN may send the required handover to the S-AMF (which may include TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, target ID, source to target transparent container, SM N2 information list, PDU session ID, intra-system handover indication, etc.). The source-to-target transparent container may include NG-RAN information created by the S-RAN for use by the T-RAN and transparent to the 5GC. It may include corresponding user plane security execution information for each PDU session, QoS flow / DRB information subject to data forwarding constraints. The PDU sessions handled by the S-RAN (e.g., all existing PDU sessions with active UP connections) may be included in the handover request message, which indicates which PDU sessions the S-RAN requests to hand over. If direct data forwarding is available, the SM N2 information may include direct forwarding path availability. Direct forwarding path availability may indicate whether direct forwarding from the S-RAN to the T-RAN is available. This indication from the S-RAN may be based on, for example, the presence of IP connectivity and security associations between the S-RAN and the T-RAN. If the source NG RAN and the target NG RAN support RACS, the source-to-target transparent container may contain the UE radio capability ID of the UE instead of the UE radio access capability. T-AMF selection may be performed. When the S-AMF is no longer able to provide services to the UE, the S-AMF may select a T-AMF based on the TSN capability support indicator, TSN bridge configuration parameters, TSN bridge ID, etc.The S-AMF may send a Namf_Communication_CreateUEContext request to the T-AMF (including TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, N2 information (target ID, source to target transparent container, SM N2 information list, PDU session ID), UE context information (SUPI, service area restriction, allowed NSSAI for each access type (if available), tracking requirement, PDU session ID together with corresponding SMF information and corresponding S-NSSAI, PCF ID, DNN, UE radio capability ID and list of UE radio capability information)). If the subscription information includes the tracking requirement, the old AMF provides the tracking requirement to the target AMF. In the case of inter-PLMN mobility, the UE context information may include TSN bridge ID, HPLMN S-NSSA I (corresponding to the allowed NSSAI for each access type without the allowed NSSAI of the source PLMN). The S-AMF may initiate the handover resource allocation procedure by calling the Namf_Communication_CreateUEContext service operation towards the T-AMF.

[0350] T-AMF may send Nsmf_PDUSession_UpdateSMContext (may include: TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, PDU session ID, target ID, T-AMF ID, N2 SM information) to SMF. For each PDU session indicated by S-RAN, AMF may call Nsmf_PDUSession_UpdateSMContext request to the associated SMF. If direct data forwarding is available between S-RAN and T-RAN and has been inserted by S-RAN, SM N2 information may include direct forwarding path availability. SMF may send N4 session modification request to UPF (PSA). If SMF selects a new UPF to act as an intermediate UPF for a PDU session and needs to use different CN tunnel information, SMF may send an N4 session modification request message to UPF (PSA). If CN tunnel information is allocated by SMF and the UL packet detection rule is associated with CN tunnel information to be installed on UPF (PSA) (on N9), SMF may provide CN tunnel information (on N9).

[0351] In the example, the UPF (PSA) may send an N4 session modification response to the SMF. The UPF (PSA) may send an N4 session establishment response message to the SMF. If the UPF (PSA) allocates the CN tunnel information of the UPF (PSA) (on N9), it provides the CN tunnel information (on N9) to the SMF. In the example, the SMF may send an Nsmf_PDUSession_UpdateSMContext response (CN tunnel information, PDU session ID, N2 SM information, reason for non-acceptance) to the T-AMF. If the N2 handover of the PDU session is accepted, the SMF may include the N2 SM information in the Nsmf_PDUSession_UpdateSMContext response, which contains the N3UP address and UL CN tunnel ID of the UPF and QoS parameters indicating that the N2 SM information is used for the target NG-RAN.

[0352] In an example, the T-AMF may send a handover request (e.g., TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, source to target transparent container, N2 MM information, N2 SM information list, tracking requirements, UE radio capability ID) to the T-RAN. In an example, the T-AMF may determine the T-RAN based on the TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, target ID, etc. The T-AMF may allocate a 5G-GUTI that is valid for the AMF and the UE in the target TAI. The source to target transparent container may be forwarded in the manner received from the S-RAN. If available in the T-AMF, the N2 MM information may include, for example, security information and a list of mobility restrictions. The T-RAN may send a handover request confirmation (target to source transparent container, a list of PDU sessions to be handed over with N2SM information, a list of PDU sessions that failed to be established due to the failure reason given in the N2 SM information element) to the T-AMF. The target to source transparent container may include a UE container having an access layer part and a NAS part. The UE container is sent transparently to the UE via T-AMF, S-AMF and S-RAN. Based on T-RAN determination, T-RAN can create a list of PDU sessions that failed to be set up and the reasons for failure (e.g., T-RAN decision, S-NSSAI unavailable, user plane security execution cannot be achieved). This information can be provided to the S-RAN. The N2 SM information in the list of PDU sessions to be handed over can include T-RAN N3 addressing information per PDU session ID, for example, the N3 UP address and tunnel ID of the T-RAN used for the PDU session. The AMF can send a Nsmf_PDUSession_UpdateSMContext request (TSN bridge configuration parameters, TSN bridge ID, TSN capability support indicator, PDU session ID, N2 SM response received from T-RAN) to the SMF. For each N2 SM response received from T-RAN (N2 SM information included in the handover request confirmation), the AMF can send the received N2 SM response to the SMF indicated by the corresponding PDU session ID. If a new T-UPF is not selected, the SMF stores the N3 tunnel information of the T-RAN from the N2 SM response in case the T-RAN accepts the N2 handover. The SMF / UPF may allocate the N3 UP address and tunnel ID for the indirect data forwarding corresponding to the data forwarding tunnel endpoint established by the T-RAN. If some QoS flows of the PDU session are not accepted by the target NG-RAN, the SMF may initiate a PDU session modification procedure to remove the unaccepted QoS flows from the PDU session after completing the handover procedure. The SMF may create an N2 SM message containing the DL forwarding tunnel information to be sent by the AMF to the S-RAN.The SMF may include this information in the Nsmf_PDUSession_UpdateSMContext response.

[0353] In such Fig.44 In the example embodiment depicted in Fig.43 and Fig.45 The procedure is such that when the S-NG-RAN decides to initiate a handover, it can send a message required for the handover to the AMF, which may include a TSN bridge ID and a list of candidate target NG-RAN nodes or base stations. The AMF or S-AMF may select the target NG-RAN node based on the elements of the message required for the handover. The S-AMF or T-AMF may send a handover request to the selected T-NG-RAN node that supports TSN and TSN bridges (e.g., has connectivity with the UPF of the TSN bridge).

[0354] In an example embodiment, a first base station may receive a time-sensitive networking bridge configuration parameter from a network node, the time-sensitive networking bridge configuration parameter including a first TSN bridge identifier, a first bridge identifier, etc. The first base station may receive a handover request message from a second base station, the handover request message may include a second TSN bridge identifier, a second bridge identifier, etc. Based on the first TSN bridge identifier matching the second TSN bridge identifier, the first base station may send a handover confirmation message indicating handover acceptance to the second base station. In an example, the network node may be an access and mobility management function (AMF), an SMF, an OAM (OA&M), a PCF, a NEF, an AF / AS, etc. The first base station may receive the TSN bridge configuration parameter in response to a PDU session establishment for a wireless device of a TSN bridge. The first base station may receive the TSN bridge configuration parameter in response to a TSN bridge configuration update performed by a session management function when configuring a UPF for a TSN bridge. In an example, the determination of acceptance or adoptability may be determined based on the connectivity of the first base station with the UPF of the TSN bridge. The first base station may send a path switch request to the AMF, the path switch request including access network tunnel information associated with the PDU session of the wireless device, a TSN bridge identifier, etc. The first base station may receive a path switch request confirmation indicating acceptance of the PDU session of the wireless device. The first base station may receive a path switch request confirmation indicating rejection of the PDU session of the wireless device. The first base station may send a configuration update message to the second base station, the configuration update message including a TSN bridge identifier, a first TSN bridge identifier, etc. The configuration update message may include a TSN bridge capability support indicator, a TSN bridge capability indicator, a bridge capability indicator, etc. The handover acceptance message may indicate the adoption of the PDU session associated with the wireless device. The first base station may receive an RRC reconfiguration complete message from the wireless device. The first base station may send a UE context release message indicating a successful handover to the second base station. The handover request message may include a network slice identifier associated with the TSN bridge. The handover acceptance may match a network slice identifier supported by the first base station or a slice identifier supported by the TSN bridge based on the network slice identifier. The handover request message may include a PDU session identifier associated with a port of the TSN bridge. The first base station may perform a mapping of the PDU session identifier to the TSN bridge ID. The TSN bridge id may include an unsigned integer value. The TSN bridge id may include a derivation of a TSN system identifier, a TSN system address, etc.

[0355] In an example embodiment, the first base station may receive a handover request message including a TSN bridge identifier from the second base station. The first base station may determine that the TSN bridge identifier does not match an element of a TSN bridge configuration parameter received from the network node. The first base station may send a handover failure message to the second base station based on the determination. The determination may include determining that a TSN bridge configuration has not been received from the network node. The determination may include receiving a TSN bridge ID, and determining to reject the request based on the TSN bridge ID not matching an element of the TSN bridge configuration parameter.

[0356] In an example embodiment, a first base station may receive a configuration setup message including a time-sensitive networking bridge configuration parameter from a second base station. The TSN bridge configuration parameter may include a first TSN bridge identifier. The first base station may receive a measurement report message including a measurement result of the second base station from a wireless device of a TSN bridge having a second TSN bridge identifier. The first base station may determine the handover of the wireless device to the second base station based on matching the first TSN bridge identifier with the second TSN bridge identifier, the measurement report, etc. The first base station may send a handover request message to the second base station. The handover request message may include a set of (TSN) bridge configuration parameters, a set of bridge attributes, a set of bridge characteristics, a TSN bridge identifier, a first TSN bridge identifier, a second TSN bridge identifier, etc. The configuration setup message includes a TSN bridge capability indicator. The first base station may send an RRC reconfiguration message including information required to access the second base station to the wireless device. The RRC reconfiguration message may include an identifier of the second base station, a C-RNTI, a second base station security algorithm identifier, a set of dedicated RACH resources, an association between RACH resources and SSBs, an association between RACH resources and UE-specific CSI-RS configurations, common RACH resources, system information of the second base station, etc.

[0357] In an example embodiment, the first base station may receive an Xn setup message including a time sensitive networking bridge configuration parameter from the second base station, wherein the TSN bridge configuration parameter may include a first TSN bridge identifier. The first base station may receive a measurement report message from a wireless device of a TSN bridge having a second TSN bridge identifier, and the measurement report message may include a measurement result of the second base station. The first base station may determine a handover of the wireless device to the second base station based on matching the first TSN bridge identifier with the second TSN bridge identifier, the measurement report, etc. The first base station may send a handover request message including the TSN bridge identifier, the first TSN bridge identifier, etc. to the second base station.

[0358] In an example embodiment, the first base station may receive an Xn setup message including a time-sensitive networking bridge configuration parameter from the second base station, wherein the TSN bridge configuration parameter may include a TSN bridge identifier. The first base station may determine the handover of the wireless device to the second base station based on at least one element of the Xn setup message, the TSN bridge configuration parameter, etc. The first base station may send a handover request message to the second base station. The first base station may receive a handover confirmation message indicating acceptance of the handover request from the second base station. The first base station may receive a measurement report message including a measurement result of the second base station from the wireless device of the TSN bridge. The determination may also be based on the measurement report. The handover request message may also include a TSN bridge identifier.

[0359] In an example embodiment, the first base station may receive a handover request message for a wireless device of a TSN bridge from the second base station. The handover request message may include a TSN bridge identifier. The first base station may determine the availability of a connection between the second base station and a user plane function of the TSN bridge based on the TSN bridge identifier. The first base station may send a handover confirmation message indicating the adoptability of the wireless device to the second base station.

[0360] In this specification, "a" and "an" and similar phrases will be interpreted as "at least one" and "one or more". In this specification, the term "may" is interpreted as, for example, "may". In other words, the term "may" indicates that the phrase after the term "may" is an example of one of multiple suitable possibilities that may or may not be used for one or more of the various embodiments. If A and B are sets, and each element of A is also an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, the possible subsets of B = {cell1, cell2} are: {cell1}, {cell2}, and {cell1, cell2}.

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

[0362] Many elements described in the disclosed embodiments can be implemented as modules. Modules are defined here as separable elements that perform defined functions and have defined interfaces to other elements. The modules described in the present disclosure can be implemented in hardware, software combined with hardware, firmware, wetware (i.e., hardware with biological elements), or a combination thereof, all of which can be equivalent in behavior. For example, a module can be implemented as a software routine written in a computer language that is configured to be executed by a hardware machine (e.g., C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (e.g., Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). In addition, it is possible to implement a module using physical hardware that incorporates discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs), such as VHSIC Hardware Description Language (VHDL) or Verilog, which configure the connections between internal hardware blocks with fewer functions on the programmable device. Finally, it is important to emphasize that the above techniques are often used in combination to achieve the results of functional blocks.

[0363] Example embodiments of the present invention may be implemented using various physical and / or virtual network elements, software defined networking, virtual network functions.

[0364] The disclosure of this patent document incorporates material which is subject to copyright protection. 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 files or records, for the limited purpose of requiring by law, but otherwise reserves all copyright rights whatsoever.

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

[0366] In addition, it should be understood that any diagrams highlighting features and advantages are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in a manner other than that shown. For example, the actions listed in any flow chart can be reordered or optionally used in certain embodiments.

[0367] In addition, the purpose of the Abstract of the Disclosure is to generally enable the U.S. Patent and Trademark Office and the public, especially scientists, engineers, and practitioners in the field who are not familiar with patent or legal terms or phraseology, to quickly determine the nature and substance of the technical disclosure of the application through a cursory review. The Abstract of the Disclosure is not intended to limit the scope in any way.

[0368] Finally, it is Applicant's intent that only claims that include the verbal language "means for" or "step for" be interpreted under 35 U.S.C. § 112. Claims that do not expressly include the phrase "means for" or "step for" should not be interpreted under 35 U.S.C. § 112.

Claims

1. A method for a communication system, the method comprising: The second base station sends a handover request for the wireless device to the first base station, wherein the handover request includes a time-sensitive networking (TSN) bridge parameter, wherein the TSN bridge parameter includes a second TSN bridge identifier; as well as A handover accept for the handover request is received by the second base station from the first base station based on the second TSN bridge identifier matching the first TSN bridge identifier associated with the first base station. 2 . The method of claim 1 , wherein the TSN bridge parameter comprises a TSN bridge capability support indicator. 3 . The method of claim 1 , wherein the second TSN bridge identifier is associated with a TSN bridge, the TSN bridge being used by the wireless device.

4. The method according to any one of claims 1 to 2, wherein: Sending the handover request is based on receiving a measurement report from the wireless device by the second base station. The method of claim 4 , further comprising sending, by the second base station, a measurement configuration to the wireless device.

6. A second base station, the second base station comprising: one or more processors; as well as A memory storing instructions, which, when executed by the one or more processors, cause the second base station to perform the method according to any one of claims 1 to 5.

7. A non-transitory computer readable medium comprising instructions which, when executed by one or more processors of a second base station, cause the second base station to perform the method of any one of claims 1 to 5.

8. A method for a communication system, the method comprising: Receiving, by the first base station from the second base station, a handover request for the wireless device, the handover request comprising time sensitive networking (TSN) bridge parameters, wherein the TSN bridge parameters comprise a second TSN bridge identifier; as well as Based on the second TSN bridge identifier matching the first TSN bridge identifier associated with the first base station, a handover accept for the handover request is sent by the first base station to the second base station.

9. The method of claim 8, wherein the TSN bridge parameter comprises a TSN bridge capability support indicator.

10. The method of any one of claims 8 to 9, wherein the second TSN bridge identifier is associated with a TSN bridge, the TSN bridge being used by the wireless device.

11. The method of claim 10, further comprising receiving, by the first base station, the first TSN bridge identifier associated with the first base station from an access and mobility management function (AMF).

12. A first base station, comprising: one or more processors; as well as A memory storing instructions which, when executed by the one or more processors, cause the first base station to perform the method of any one of claims 8 to 11.

13. A non-transitory computer readable medium comprising instructions which, when executed by one or more processors of a first base station, cause the first base station to perform the method of any one of claims 8 to 11.

14. A system for communication, the system comprising: A second base station, wherein the second base station comprises: one or more processors; and a memory storing instructions that, when executed by the one or more processors of the second base station, cause the second base station to: sending a handover request for the wireless device to the first base station, the handover request comprising time sensitive networking (TSN) bridge parameters, wherein the TSN bridge parameters comprise a second TSN bridge identifier; and receiving a handover acceptance for the handover request from the first base station based on the second TSN bridge identifier matching the first TSN bridge identifier associated with the first base station; and the first base station, wherein the first base station comprises: one or more processors; and a memory storing instructions that, when executed by the one or more processors of the first base station, cause the first base station to: receiving the handover request from the second base station; and The handover accept is sent to the second base station based on the second TSN bridge identifier matching the first TSN bridge identifier associated with the first base station.

Images