WO2024078753A1

WO2024078753A1 - Access path switching

Info

Publication number: WO2024078753A1
Application number: PCT/EP2023/067176
Authority: WO
Inventors: Apostolis Salkintzis
Original assignee: Lenovo (Singapore) Pte. Ltd.
Priority date: 2023-06-12
Filing date: 2023-06-23
Publication date: 2024-04-18

Abstract

A User Equipment (UE) configured to perform a first registration with a core network via a first access network and a second registration with the core network via a second access network, and to initiate establishment of a multiaccess data connection comprising a first and second access paths associated with the first and second registrations respectively. The UE is configured to receive first and second access path identities associated with the first access path and the second access path respectively. The UE is further configured to initiate a third registration with the core network, via a third access network, including providing to the core network a source access path identity, and to initiate a switching of one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

Description

ACCESS PATH SWITCHING

Technical field

The technical field is an access path switching procedure applicable in particular to an Access Traffic Steering, Switching, and Splitting feature of 3GPP, allowing a User Equipment to utilize multiple access paths simultaneously.

Background

The 3rd Generation Partnership Project (3GPP™) is an umbrella term for a number of standards organizations which develop protocols for mobile telecommunications. 3GPP is currently in the process of developing standards for 5G NR and related 5G standards, including 5G-Advanced.

The Access Traffic Steering, Switching, and Splitting (ATSSS) feature, as outlined in the 3GPP Release 18 specifications, provides enhanced data communication capabilities by allowing a User Equipment (UE) to utilize multiple access paths simultaneously. This is achieved by establishing a multiaccess data connection (referred to in the 3GPP specs as Multiaccess Packet Data Unit (MA PDU) session) that supports two access paths, one 3GPP access path, using an access network defined by 3GPP such a NG-RAN, and one non-3GPP access path, using an access network not defined by 3GPP such as WiFi™. Every data packet that should be transmitted via the multiaccess data connection is transmitted either over the 3GPP access path or over the non-3GPP access path, according to multiaccess rules (also known as ATSSS rules), which are provided to a User equipment (UE) during the establishment of the multiaccess data connection.

In addition to the multiaccess transmission capability, the ATSSS feature supports also a capability known as "non-3GPP access path switching," which enables a UE to switch its non-3GPP access path between different non-3GPP access networks. In a typical example, a UE initially establishes a non-3GPP access path via an "untrusted" non- 3GPP access network, served by a non-3GPP Interworking Function (N3IWF). This non- 3GPP access path can be subsequently switched to a "trusted" non-3GPP access network, served by a Trusted Non-3GPP Gateway Function (TNGF). After the switching process, the UE maintains its Multiaccess PDU (MA PDU) Session and continues data communication using both the 3GPP access path and the newly switched non-3GPP access path.

Use of a non-3GPP access path switching can be beneficial for a number of reasons including enhanced security, improved connectivity, or optimized network usage. For example, a UE might switch from an untrusted to a trusted network when it detects a degradation in service quality.

Figure 1 illustrates the key principle of the “non-3GPP access path switching” procedure (defined in Release 18 specifications) which enables the switching of a non-3GPP access path of an MA PDU Session, from a source non-3GPP access path to a target non-3GPP access path, both included in the same 5G Core (5GC) network (or PLMN). The switching procedure is triggered by a Registration Request message sent by the UE over the target non-3GPP access path. When the 5GC network receives this message it determines that the UE wants to switch the existing (source) non-3GPP access path to a new (target) non-3GPP access path. Note that the UE has also a 3GPP access path (as part of the established MA PDU Session) but switching this 3GPP access path to a new non-3GPP access path is not specified in Release 18. Therefore, by sending the Registration Request message via the new non-3GPP access path, the 5GC network implicitly determines which of the existing access paths of the MA PDU Session should be transferred (switched) to the access path via which the Registration Request was received.

It is noted that, whilst the principle illustrated in Figure 1 has been applied to support non-3GPP access path switching, the same principle can be applied to support 3GPP access path switching, i.e., switching a source 3GPP access path to a target 3GPP access path, both included in the same 5G Core (5GC) network (or Public Land Mobile Network (PLMN)).

In the context of Release 19 of the 3GPP specifications, new requirements are being introduced to support further scenarios for access path switching. According to these requirements, it should be possible to support the following additional access path switching scenarios: • Source 3GPP access path switched to a target 3GPP access path (3GPP to 3GPP).

• Source non-3GPP access path switched to a target 3GPP access path (non- 3GPP to 3GPP).

• Source 3GPP access path switched to a target non-3GPP access path (3GPP to non-3GPP).

The first two scenarios are schematically illustrated in Figures 2 and 3 respectively.

The existing “non-3GPP access path switching” procedure as defined in Release 18 (described above with respect to Figure 1) cannot be applied to these further scenarios. This is because the Registration Request sent by the UE to trigger the access switching procedure does not indicate the source access path and, hence, the 5GC network cannot unambiguously determine the source access path that the UE wishes to switch to the target access path. For example, in the scenario shown in Figure 2, the UE has a MA PDU Session composed of two 3GPP access paths. When the 5GC network receives the Registration Request message via the target 3GPP access path, it cannot determine which of the existing two 3GPP access paths the UE wishes to switch to the target access path. A similar issue arises in the scenario shown in Figure 3.

In some cases, the MA PDU Session can be composed of more than two access paths, e.g., two 3GPP access paths and one non-3GPP access, for example where a UE is simultaneously using terrestrial 3GPP access, non-terrestrial 3GPP access (via satellite), and non-3GPP access via Wi-Fi. The above issue arises in such cases too, as the Registration Request message does not carry enough information to unambiguously indicate the source access path to be transferred.

Relevant background is presented in particular in the “non-3GPP access path switching” procedure defined in TS 23.502 v18.1.1 , clause 4.22.9.5, “Registration procedures for non-3GPP access path switching”. The reader is also referred to disclosure SMM920220014-GR-NP “PATH SWITCHING BETWEEN NON-3GPP ACCESS PATHS”, Lenovo™, which specifies a method for enabling non-3GPP access path switching, i.e. , to transfer a source non-3GPP access path to a target non-3GPP access path. The method in SMM920220014-GR-NP is applicable only to switching a non-3GPP access path. Summary of invention

According to a first aspect of the invention there is provided a User Equipment comprising a transceiver and processing circuitry configured to perform a first registration with a core network of a mobile communication network, via a first access network, perform a second registration with the core network, via a second access network, and establish a multiaccess data connection with the core network comprising a first access path associated with the first registration and a second access path associated with the second registration. The processing circuitry is configured to receive, from the core network, first and second access path identities associated with the first access path and the second access path respectively. The processing circuitry is further configured to initiate a third registration with the core network, via a third access network, including providing to the core network one of the first and second path identities as a source access path identity, and switch one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

According to a second aspect of the present invention there is provided a network device for use in a core network of a mobile communication network and comprising a transceiver and processing circuitry configured to perform a first registration of a User Equipment, via a first access network, perform a second registration of the User Equipment, via a second access network, and initiate establishment of a multiaccess data connection with the User Equipment comprising a first access path associated with the first registration and a second access path associated with the second registration. The processing circuitry is configured to send to the User Equipment first and second access path identities associated with the first access path and the second access path respectively. The transceiver and processing circuitry are further configured to initiate a third registration of the User Equipment, via a third access network, including receiving from the User Equipment one of the first and second path identities as a source access path identity, and initiate switching of one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

The network node may be configured to operate as an Access and Mobility Management Function (AMF) of a 5G core network. The transceiver and processing circuitry may be configured to initiate establishment of a multiaccess data connection with the User Equipment by forwarding a request from the UE to a Session Management Function (SMF) of the 5G core network.

The transceiver and processing circuitry may be configured to initiate switching of one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path by forwarding a request from the UE to a Session Management Function (SMF) of the 5G core network.

According to a third aspect of the present invention there is provided a method implemented at a User Equipment and comprising performing a first registration with a core network of a mobile communication network, via a first access network, performing a second registration with the core network, via a second access network, and establishing a multiaccess data connection with the core network comprising a first access path associated with the first registration and a second access path associated with the second registration. The User Equipment receives, from the core network, first and second access path identities associated with the first access path and the second access path respectively, initiates a third registration with the core network, via a third access network, including providing to the core network one of the first and second path identities as a source access path identity, and switches one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

According to a further aspect of the present invention there is provided a network device for use in a core network of a mobile communication network and comprising a transceiver and processing circuitry configured to receive a request to initiate establishment of a multiaccess data connection with a User Equipment and comprising a first access path associated with a first registration and a second access path associated with a second registration, the request including first and second access path identities associated with the first access path and the second access path respectively. The transceiver and processing circuitry are further configured respond to said request by establishing the multiaccess data connection with the User Equipment. The transceiver and processing circuitry are further configured to receive a request to initiate switching of one of the access paths of the multiaccess data connection from the first or second access path, identified by a source access path identity contained in the request, to a third access path associated with the third registration, and to respond by completing the switching.

The network entity of the further aspect may be configured to operate as a Session Management Function (SMF).

Brief description of drawings

Figure 1 illustrates schematically a non-3GPP access path switching procedure defined in Release 18 specifications and which enables the switching of a non-3GPP access path from a source non-3GPP access path to a target non-3GPP access path;

Figure 2 illustrates a required 3GPP access path switching procedure of Release 19 specifications and which involves the switching of a 3GPP access path from a source 3GPP access path to a target 3GPP access path;

Figure 3 illustrates a required 3GPP access path switching procedure of Release 19 specifications and which involves the switching of a 3GPP access path from a source non-3GPP access path to a target 3GPP access path;

Figure 4 illustrates schematically a mobile communication system including a 5G core network and a User Equipment;

Figure 5 illustrates an access path switching procedure according to an embodiment and which involves the switching of an access path from a source access path to a target access path using access path identities;

Figure 6 illustrates signalling in the network of Figure 4 according to an embodiment;

Figure 7 illustrates signalling in the network of Figure 4 according to an embodiment;

Figure 8 is a flow diagram illustrating an embodiment;

Figure 9 illustrates schematically an embodiment of a User Equipment; and

Figure 10 illustrates schematically an embodiment of a network apparatus.

Detailed description

As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects.

For example, the disclosed embodiments may be implemented as a hardware circuit comprising custom very-large-scale integration (“VLSI”) circuits or gate arrays, off-the- shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code which may, for instance, be organized as an object, procedure, or function.

Furthermore, embodiments may take the form of a program product embodied in one or more computer readable storage devices storing machine readable code, computer readable code, and/or program code, referred hereafter as code. The storage devices may be tangible, non-transitory, and/or non-transmission. The storage devices may not embody signals. In a certain embodiment, the storage devices only employ signals for accessing code.

Any combination of one or more computer readable medium may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a portable compact disc read-only memory (“CD-ROM”), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages. The code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (“LAN”), wireless LAN (“WLAN”), or a wide area network (“WAN”), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider (“ISP”)).

Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that embodiments may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment.

Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but mean “one or more but not all embodiments” unless expressly specified otherwise. The terms “including,” “comprising,” “having,” and variations thereof mean “including but not limited to,” unless expressly specified otherwise. An enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms “a,” “an,” and “the” also refer to “one or more” unless expressly specified otherwise.

As used herein, a list with a conjunction of “and/or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and/or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one or more of” includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C. As used herein, a list using the terminology “one of” includes one and only one of any single item in the list. For example, “one of A, B and C” includes only A, only B or only C and excludes combinations of A, B and C. As used herein, “a member selected from the group consisting of A, B, and C,” includes one and only one of A, B, or C, and excludes combinations of A, B, and C.” As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

Aspects of the embodiments are described below with reference to schematic flowchart diagrams and/or schematic block diagrams of methods, apparatuses, systems, and program products according to embodiments. It will be understood that each block of the schematic flowchart diagrams and/or schematic block diagrams, and combinations of blocks in the schematic flowchart diagrams and/or schematic block diagrams, can be implemented by code. This code may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

The code may also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function/act specified in the flowchart diagrams and/or block diagrams.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

The call-flow diagrams, flowchart diagrams and/or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatuses, systems, methods, and program products according to various embodiments. In this regard, each block in the flowchart diagrams and/or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of the code for implementing the specified logical function(s).

It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the illustrated Figures.

Although various arrow types and line types may be employed in the call-flow, flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the depicted embodiment. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted embodiment. It will also be noted that each block of the block diagrams and/or flowchart diagrams, and combinations of blocks in the block diagrams and/or flowchart diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and code. The description of elements in each figure may refer to elements of proceeding figures. Like numbers refer to like elements in all figures, including alternate embodiments of like elements.

To address the problem discussed above, namely the challenge of switching an access path from a given source access path amongst a plurality of source paths to a target access path, amendments are proposed to the existing “non-3GPP access path switching” procedure, specified in TS 23.502 v18.1.1 , clause 4.22.9.5, “Registration procedures for non-3GPP access path switching”. These amendments extend the procedure and make it capable of supporting not only non-3GPP access path switching (non-3GPP to non-3GPP), but also all the additional three access path switching scenarios introduced in Release 19.

Figure 4 illustrates a remote unit 105 (UE) connected to a 5G core (5GC) network 140 via two types of access networks:

(1) a 3GPP access network 110 (“First Access Network”) comprising a Cellular Base Station 111 to which the UE is connected, and

(2) a non-3GPP access network 120 (“Second Access Network”) comprising an Access Point 121 to which the UE is also connected.

The First Access Network 110 uses a 3GPP-defined type of wireless communication (e.g., NG-RAN), while the Second Access Network 120 uses a non-3GPP-defined type of wireless communication (e.g., WLAN/Wi-Fi). The Second Access Network is connected to the 5GC network via a suitable Interworking Function 122 (e.g., a N3IWF or TNGF). The 5G-RAN 118 in the Figure refers to any type of 5G access network that can provide access to the 5GC 140, including the 3GPP access network 120 and the non-3GPP access network 130.

Present within the 5GC network are several functional entities known in the art, including the following functional entities:

Unified Data Management (UDM) 149.

Session Management Function (SMF) 145

Access and Mobility Management Function (AMF) 143

Policy Control Function (PCF) 147

User Plane Function (UPF) 141. The UE 105 can establish a multiaccess data connection 148 with the UPF 141 in the 5GC 140 and which can support data communication using multiple access types including data communication 113 with the (first) access type of the First Access Network 110 (e.g., NG-RAN) and data communication 123 with the (second) access type of the Second Access Network 120 (e.g., Wi-Fi access). The multiaccess data connection 148 is also known as a “multiaccess PDU Session” and supports two user-plane connections: one user-plane connection using communication over 3GPP access 115 and another user-plane connection using communication over non-3GPP access 125. In general, a MA PDU Session may have two or more user-plane connections, each one using communication over a different type of access network. Each user-plane connection is also referred to as an “access path”. For example, in Figure 4 the user-plane connection using communication over 3GPP access 115 is also referred to as first access path 115, and the user-plane connection using communication over non-3GPP access 125 is also referred to as second access path 125.

During the establishment of the MA PDU session 148, the PCF 147 creates steering rules, which are translated by the SMF 145 to steering rules 108 for the Uplink (UL) traffic and steering rules 109 for the Downlink (DL) traffic and which rules are forwarded to the UE 105 and to UPF 141 respectively. The steering rules for the Uplink (UL) traffic are called ATSSS rules, and the steering rules for the Downlink (DL) traffic are called Multi Access Rules (MAR). The steering rules specify how the UL traffic and how the DL traffic of the MA PDU Session is to be routed across the two user-plane connections, or across the access paths of the MA PDU Session.

The UE 105 may use the MA PDU Session 148 to communicate with a Remote Host 155, connectable via a Data Network 150.

Figure 4 further illustrates a Third Access Network 130 of a third access type, which type may be the same as or different from the access types of the First and Second Access Networks. It is assumed that the UE 105 can connect to the Third Access Network 130 via a Cellular Base Station 131 although no MA PDU Session access path has yet been established via the Third Access Network 130. The UE can apply the procedure specified below to switch either the first access path 115 or the second access path 125 of the MA PDU Session to a third access path (not shown) established via the Third Access Network 130. The third access path will use user-plane resources between the remote unit (UE) 105 and the UPF 141 , via the Third Access Network 130.

The existing principle of non-3GPP Access Path Switching specified in Rel-18 specifications (see Figure 1) is amended as shown in Figure 5. In this amended approach, each access path of a MA PDU Session has an identity which is assigned by the AMF 143 during the registration procedure. When the UE 105 wants to switch a source access path to a target access path (e.g. the “third access path”) the UE sends a Registration Request message to the AMF 143 over the third access path and includes in this message the identity of the source access path that is to be transferred. Each access path can be either a 3GPP access path or a non-3GPP access path. Therefore, the principle shown in Figure 5 can be used to (a) switch a 3GPP access path to another 3GPP access path, or (b) switch a 3GPP access path to a non-3GPP access path, or (c) switch a non-3GPP access path to a 3GPP access path.

Note that the access networks shown in Figure 5 may be of different types or may be of the same type. For example, the first access network and the third access network could both be terrestrial NG-RAN networks.

Figure 6 illustrates in detail a modified procedure for (a) MA PDU Session Establishment and (b) Access Path Switching. It illustrates in particular the following steps:

Step 1 : The UE registers to the 5G core network via a first access network node (e.g., gNB-1) in a first access network. The existing 5G registration procedure is applied. In addition, if the AMF supports ATSSS and access path switching, it assigns an access path identity and provides this to the UE within the Registration Accept message. This access path identity can later be used by the UE to indicate that an MA PDU Session should establish user-plane resource over the first access network, or to indicate that this access path should be switched to a different access path. The access path identity assigned by the AMF may be either a numeral value (e.g., “70”, “71”, etc.) or another type of value.

Step 2: The UE registers to the 5G core network via a second access network node (e.g., a gNB-2) in a second access network, using the same procedure as in step 1 . Note that second access network could be the same type or different type from the first access network. For example, the first access network could be a terrestrial 3GPP access network, while the second access network could either a terrestrial 3GPP access network (using a different gNB) or a non-3GPP access network, such as a Wi-Fi network.

Steps 3, 4: An MA PDU Session is established that can transfer data over the first access path and the second access path.

The UE sends an UL NAS Transport message to the AMF containing a PDU Session Establishment Request message. The UE indicates to the AMF that (a) it requests a MA PDU session, (b) it supports access path switching and (c) it wants the MA PDU Session to comprise a first access path and a second access path. The last component (c) is optional and, when not provided, the AMF assumes that the MA PDU Session should contain all the access paths via which the UE is already registered. The “access path switching supported” indication is an extension of the existing “non-3GPP access path switching supported” indication and indicates that the UE supports path switching for all types of accesses.

The AMF sends a Nsmf_PDUSession_CreateSMContext Request message to the SMF in order to establish the user-plane resources for the requested MA PDU Session. This message indicates that both the UE and the AMF support access path switching, and it also indicates the identities of the access paths on which user-plane resources should be established. The SMF selects a UPF for the MA PDU Sessions and establishes an N4 Session with the selected UPF.

In step 4a, the SMF sends an Namf_Communication_N1 N2MessageTransfer Request message, which contains the first access path identity indicating that the AMF should establish user-plane resources over the first access path. This message contains also a PDU Session Establishment Accept message (not shown in the Figure) which should be transferred to the UE via the first access path. This message indicates that the SMF supports access path switching, so the UE may later initiate an access path switching procedure (as in step 6). It also contains ATSSS rules which are applied by the UE to determine how to route uplink traffic across the first access path and the second access path.

After the user-plane resources over the first access path are established, the SMF sends to the AMF (in step 4f) another Namf_Communication_N1 N2MessageTransfer Request message, which contains the second access path identity indicating that the AMF should establish user-plane resources over the second access path. Step 5: After the establishment of the MA PDU Session, user-plane traffic is transmitted over the first access path and the second access path based on the ATSSS rules provided to UE and based on the multiaccess N4 rules provided to UPF.

Step 6: The UE initiates an access path switching procedure to transfer the second access path to a third access path. For this purpose, the UE sends another Registration Request message to the AMF via the third access path. In this message the UE includes the identity of the MA PDU Session (in the List of PDU Session to be Activated) and requests “path switching while using old resources”, i.e., to maintain the user-plane resources via the old (source) access path until the user-plane resource via the new (target) access path are established. In addition to these existing parameters, the UE includes the identity of the source access path that should be switched to the third access path.

The AMF sends an Nsmf_PDUSession_UpdateSMContext Request message to the SMF to trigger the establishment of user-plane resources over the third access path and to release the user-plane resources for the second access path in the UPF. The AMF assigns an identity to the third access path and includes in the request message the identity of the third access path (target) and the identity of the second access path (source).

The SMF establishes the user-plane resources over the third access path and then the AMF triggers the release of the user-plane resources over the second access path. Finally, the AMF sends a Registration Accept message to the UE to indicate that the UE has registered via the third access path and that the second access path has been successfully transferred to the third access path. In the message, the AMF includes the identity of the third access path, which may be used later by the UE to refer to this access path (e.g., to switch it to another access path).

Step 7: After the access path switching is completed, the user-plane traffic of the MA PDU Session is transmitted over the first access path and the third access path based on the ATSSS rules provided to UE and based on the multiaccess N4 rules provided to UPF.

Figure 7 illustrates an alternative procedure that can be used to implement access path switching satisfying the requirements of Release 19. This involves the following steps. The UE registers to the 5G core network via a first access network node (e.g., gNB-1) in a first access network, and registers also to the 5G core network via a second access network node (e.g., gNB-2) in a second access network. Note that the second access network could be the same as or different from the first access network. For example, the first access network could be a terrestrial 3GPP access network while the second access network could either a terrestrial 3GPP access network (using a different gNB) or a non-3GPP access network, such as a Wi-Fi network. In this case, the registration procedures are executed with no changes. Up to this point no access path identifiers have been exchanged.

The UE sends an UL NAS Transport message to the AMF containing a PDU Session Establishment Request message. In this case, this message does not contain the identities of the access paths that should be supported by the MA PDU Session. This means that the UE essentially requests the MA PDU Session to support all access paths via which the UE has registered to the 5GC. The “access path switching supported” indication is an extension of the existing “non-3GPP access path switching supported” indication and indicates that the UE supports path switching for all types of accesses.

The AMF sends a Nsmf_PDUSession_CreateSMContext Request message to the SMF in order to establish the user-plane resources for the requested MA PDU Session. This message indicates that both the UE and the AMF support access path switching, and it also indicates the identities of the access paths on which the user-plane resources should be established. These identities are assigned by the AMF. In the example shown in Figure 7 the AMF knows that the UE is registered via two access paths, so it assigns an identity to each one of these access paths. The SMF selects a UPF for the MA PDU Sessions and establishes an N4 Session with the selected UPF.

In step 4a, the SMF sends an Namf_Communication_N1 N2MessageTransfer Request message, which contains the first access path identity indicating that the AMF should establish user-plane resources over the first access path. This message contains also a PDU Session Establishment Accept message (not shown in the Figure) which should be transferred to the UE via the first access path. This message indicates that the SMF supports access path switching so that the UE may later initiate an access path switching procedure (as in step 6). It also contains ATSSS rules, which are applied by the UE to determine how to route uplink traffic across the first access path and the second access path. Moreover, the PDU Session Establishment Accept message contains the access path identities assigned by the AMF and provided to the SMF in step 3b. In this way the UE is informed about the identity associated with each access path of the MA PDU Session.

Each access path identity assigned by the AMF may be either a numeral value associated with an access type (e.g., “70” for the path over untrusted non-3GPP access and “71” for the path over NR-LEO) or a descriptive value (e.g., “NR-LEO” or “untrusted non-3GPP access” or “E-UTRA”, etc.). In the case where two or more access paths are using the same radio access technology (RAT), e.g., NR access, the access path must be distinguished using additional information such as NAS counters or other NAS parameters which are unique per access path. Note that each access path is associated with a NAS signalling connection between the UE and the AMF.

In contrast with the procedure described with respect to Figure 6, where the access path identities are assigned during the registration procedure and each identity received by the UE is implicitly associated with the access path via which the registration was performed, the procedure of Figure 7 requires that each access path identity received by the UE must be explicitly associated with an access path.

After the user-plane resources over the first access path are established, the SMF sends to the AMF (in step 4f) another Namf_Communication_N1 N2MessageTransfer Request message, which contains the second access path identity indicating that the AMF should establish user-plane resources over the second access path.

Steps 5-7: These are the same as the correspondingly numbered steps of Figure 6.

Note that in step 6e, the third registration request contains the source access path identity and the third registration accept contains the target access path identity. The registration procedure is still impacted (as it needs to support new information elements), but this is only needed when the registration is used for access path switching. In all other cases, the registration procedure is not impacted.

Figure 8 is a flow diagram illustrating various steps in a method implemented at a User Equipment. Illustrated specifically are the following steps:

600: Performing a first registration with a core network of a mobile communication network, via a first access network; 601 : Performing a second registration with the core network, via a second access network; and

602: Establishing a multiaccess data connection with the core network comprising a first access path associated with the first registration and a second access path associated with the second registration,

601a: The User Equipment receives, from the core network, first and second access path identities associated with the first access path and the second access path respectively. NB. This step may be performed at any suitable point or points during or after step 600.

603: Performing a third registration with the core network, via a third access network, including providing to the core network one of the first and second path identities as a source access path identity;

604: Switching one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

Figure 9 depicts a user equipment (UE) apparatus 700 that, in various embodiments, is used to implement one or more of the solutions described above. The user equipment apparatus 700 may include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725.

In some embodiments, the input device 715 and the output device 720 are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus 700 may not include any input device 715 and/or output device 720. In various embodiments, the user equipment apparatus 700 may include one or more of: the processor 705, the memory 710, and the transceiver 725, and may not include the input device 715 and/or the output device 720.

As depicted, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735. In some embodiments, the transceiver 725 communicates with one or more cells (or wireless coverage areas) supported by one or more base units 121. Additionally, the transceiver 725 may support at least one network interface 740 and/or application interface 745. The application interface(s) 745 may support one or more APIs. The network interface(s) 740 may support 3GPP reference points, such as Uu, N1 , PC5, etc. Other network interfaces 740 may be supported, as understood by one of ordinary skill in the art.

The processor 705, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

In various embodiments, the processor 705 controls the user equipment apparatus 700 to implement the above described UE behaviors. In certain embodiments, the processor 705 may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.

Figure 10 depicts a network apparatus 800 that may be present within the core network, according to embodiments of the disclosure. The network apparatus 800 may include a processor 805, a memory 810, an input device 815, an output device 820, and a transceiver 825.

In some embodiments, the input device 815 and the output device 820 are combined into a single device, such as a touchscreen. In certain embodiments, the network apparatus 800 may not include any input device 815 and/or output device 820. In various embodiments, the network apparatus 800 may include one or more of: the processor 805, the memory 810, and the transceiver 825, and may not include the input device 815 and/or the output device 820.

As depicted, the transceiver 825 includes at least one transmitter 830 and at least one receiver 835. Here, the transceiver 825 communicates with one or more UEs via one or more intermediate components. Additionally, the transceiver 825 may support at least one network interface 840 and/or application interface 845. The application interface(s) 845 may support one or more APIs.

The processor 805, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor 805 may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. In some embodiments, the processor 805 executes instructions stored in the memory 810 to perform the methods and routines described herein. The processor 805 is communicatively coupled to the memory 810, the input device 815, the output device 820, and the transceiver 825.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the claims.

Claims

1. A User Equipment comprising a transceiver and processing circuitry configured to: perform a first registration with a core network of a mobile communication network, via a first access network; perform a second registration with the core network, via a second access network; and establish a multiaccess data connection with the core network comprising a first access path associated with the first registration and a second access path associated with the second registration, wherein the processing circuitry is configured to receive, from the core network, first and second access path identities associated with the first access path and the second access path respectively, the processing circuitry being further configured to: initiate a third registration with the core network, via a third access network, including providing to the core network one of the first and second path identities as a source access path identity; switch one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

2. A User Equipment according to any one of the preceding claims, the transceiver and processing circuitry being configured to establish a multiaccess data connection with the core network comprising the first access path and the second access path by sending a multiaccess data connection establishment request to the core network and receiving from the core network a multiaccess data connection establishment accept.

3. A User Equipment according to claim 1 or 2, the transceiver and processing circuitry being configured to: perform said first, second and third registrations by sending, via respective access networks, respective first, second and third registration requests to register to the core network and to receive respective first, second and third registration accepts.

4. A User Equipment according to claim 3, the transceiver and processing circuitry being configured to receive said first and second access path identities in the first and second registration accepts respectively.

5. A User Equipment according to claim 3 or 4, wherein the third registration accept contains a third access path identity associated with the third access path.

6. A User Equipment according to claim 4 when dependent upon claim 2, wherein the multiaccess data connection establishment accept contains the first and second access path identities.

7. A User Equipment according to claim 2, the transceiver and processing circuitry being configured to include in the multiaccess data connection establishment request an indication that the User equipment supports path switching for all types of accesses.

8. A User Equipment according to claim 2, wherein the multiaccess data connection establishment request contains the first and second access path identities.

9. A User Equipment according to any one of the preceding claims, wherein the transceiver comprises one or more radio access interfaces for communicating via the first, send and third access networks.

10. A User Equipment according to claim 9, the or each radio interface being one of a 3GPP radio interface, a Wi-Fi radio interface, and a WLAN radio interface.

11. A User Equipment according to claim 10, the 3GPP radio interface being a NG- RAN radio interface.

12. A User Equipment according to any one of the preceding claims, wherein said core network is a 5G core network and the multiaccess data connection is a Multiaccess Packet Data Unit, MA PDU, session.

13. A User Equipment according to any one of the preceding claims, wherein the first and second access paths are: both non-3GPP access paths; or both 3GPP access paths, or one of the first and second access paths is a 3GPP access path and the other is a non-3GPP access path.

14. A User Equipment according to claim 13, wherein the third access path is one of a 3GPP access path and a non-3GPP access path.

15. A network device for use in a core network of a mobile communication network and comprising a transceiver and processing circuitry configured to: perform a first registration of a User Equipment, via a first access network; perform a second registration of the User Equipment, via a second access network; and initiate establishment of a multiaccess data connection with the User Equipment comprising a first access path associated with the first registration and a second access path associated with the second registration, wherein the processing circuitry is configured to send to the User Equipment first and second access path identities associated with the first access path and the second access path respectively, the transceiver and processing circuitry being further configured to: initiate a third registration of the User Equipment, via a third access network, including receiving from the User Equipment one of the first and second path identities as a source access path identity; initiate switching of one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.

16. A network device according to claim 15, the transceiver and processing circuitry being configured to initiate establishment a multiaccess data connection by relaying a multiaccess data connection establishment request received from the User equipment to a Session Management Function and relaying a multiaccess data connection establishment accept received from the Session Management Function to the User equipment.

17. A network device according to claim 14 or 15, the transceiver and processing circuitry being configured to send said first and second access path identities in a first and a second registration accept respectively.

18. A network device according to claim 16, the multiaccess data connection establishment accept containing the first and second access path identities.

19. A network device according to any one of claims 14 to 18, the transceiver and processing circuitry operating as an Access and Mobility Management Function with the core network.

20. A method implemented at a User Equipment and comprising: performing a first registration with a core network of a mobile communication network, via a first access network; performing a second registration with the core network, via a second access network; and establishing a multiaccess data connection with the core network comprising a first access path associated with the first registration and a second access path associated with the second registration, wherein the User Equipment receives, from the core network, first and second access path identities associated with the first access path and the second access path respectively, initiating a third registration with the core network, via a third access network, including providing to the core network one of the first and second path identities as a source access path identity; switching one of the access paths of the multiaccess data connection from the first or second access path, identified by the source access path identity, to a third access path associated with the third registration.