Establishing multiple access connections

Abstract

The invention relates to establishing multiple access connections. A user equipment (UE) may be configured to re-attempt to establish a multiple access (MA) protocol data unit (PDU) session when the UE moves to a new registration area. The UE transmits a request for an MA PDU session to the network, receives a message from the network indicating that the request has been rejected, where the message further includes a status indication of a re-attempt request to establish the MA PDU session, determines whether a re-attempt request is allowed based at least on the status indication when the UE moves into a new registration area of a PLMN, and if the re-attempt request is not allowed, determines whether the re-attempt request is not allowed based on the status indication. And transmitting a further request to establish the MA PDU session when the request is allowed to be re-attempted.

Description

[0001] This application is a divisional application of the invention patent application with application number 202011205547.7, filed on November 2, 2020, and invention name “Establishing Multiple-Address Connections”. Technical Field

[0002] The present application relates to establishing multiple access connections. Background Art

[0003] A user equipment (UE) can establish a connection with at least one of multiple different networks or network types. Some networks allow multiple access (MA). MA allows multiple UEs to share channels in an allocated spectrum. Single access (SA) does not allow such sharing. Therefore, MA generally uses bandwidth more efficiently than SA. However, not all networks support MA in all geographic areas.

[0004] In a 5G New Radio (5G NR) network, a UE may request the network to establish an MA session for the UE by using a Multiple Access Protocol Data Unit (MA-PDU). The network may accept the MA-PDU and establish an MA session for the UE. On the other hand, the network may reject the MA-PDU and not establish an MA session. There may be multiple rejection reasons, some of which will be discussed in more detail below. When the UE receives a rejection, the UE may want to re-request an MA session. However, in some cases, it may be inefficient for the UE to re-request an MA session with the network because the network is unlikely to establish an MA session. Summary of the invention

[0005] Some exemplary embodiments relate to a user equipment (UE) having: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations. The operations include: transmitting a request for a multiple access (MA) protocol data unit (PDU) session with the network, receiving a message from the network indicating that the request has been rejected, wherein the message also includes a status indication of a retry request to establish the MA PDU session, when the UE moves to a new registration area of ​​a PLMN, determining whether to allow the retry request based on at least the status indication, and when the retry request is allowed, transmitting an additional request to establish the MA PDU session.

[0006] Other exemplary embodiments relate to a method performed at a wireless network. The method includes: receiving a request for a multiple access (MA) protocol data unit (PDU) session from a user equipment (UE); and transmitting a message indicating that the request has been rejected, wherein the message also includes a status indication of a retry request to establish the MA PDU session.

[0007] Still other exemplary embodiments relate to a user equipment (UE) having: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations. The operations include: registering with an access and mobility management function (AMF); and receiving an indication that access traffic steering, switching, and splitting (ATSSS) is not supported in a registration area.

[0008] Additional exemplary embodiments relate to a method performed by an access and mobility management function (AMF) or a mobility management entity (MME) of a wireless network. The method includes: receiving an indication that a user equipment (UE) is configured with access traffic steering, switching and splitting (ATSSS); determining that the AMF does not support ATSSS; and selecting another AMF for the UE. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 Exemplary network arrangements are shown according to various exemplary embodiments.

[0010] Figure 2 An exemplary UE according to various exemplary embodiments is shown.

[0011] Figure 3 Exemplary information elements (IEs) that may be included in a PDU SESSION ESTABLISHMENT REJECT message or a PDU SESSION ESTABLISHMENT ACCEPT message according to various exemplary embodiments are shown.

[0012] Figure 4 A second exemplary IE is shown that may be included in a PDU SESSION ESTABLISHMENT REJECT message or a PDU SESSION ESTABLISHMENT ACCEPT message according to various exemplary embodiments.

[0013] Figure 5 An exemplary method for a UE to trigger a re-attempt to establish an MA session according to various exemplary embodiments is shown.

[0014] Figure 6 An exemplary signaling diagram illustrating a network-triggered re-attempt to establish an MA session is shown in accordance with various exemplary embodiments.

[0015] Figure 7 A signaling diagram related to the UE providing ATSSS capability information to the AMF according to various exemplary embodiments is shown.

[0016] Figure 8 A signaling diagram related to the AMF providing ATSSS capability information to the UE according to various exemplary embodiments is shown.

[0017] Fig. 9A signaling diagram related to the AMF providing ATSSS capability information to the UE according to various exemplary embodiments is shown. DETAILED DESCRIPTION

[0018] The exemplary embodiments may be further understood with reference to the following description and associated drawings, in which similar elements have the same figure numbers. The exemplary embodiments relate to a user equipment (UE) establishing a multiple access (MA) session with a network. In a first aspect, the exemplary embodiments relate to the UE and the network exchanging capability information about MA functionality. As described below, this allows the UE and the network to consider the MA functionality during network registration. In a second aspect, the exemplary embodiments relate to determining when the UE requests an MA session with the network (after the network has previously rejected such a request). As described below, the exemplary embodiments improve the efficiency of the UE by preventing the UE from making an MA request when it is unlikely to be granted, but allowing the UE to make a request when there is a chance that the request will be granted.

[0019] The exemplary embodiments are described with respect to UE. However, the use of UE is provided for illustration purposes only. The exemplary embodiments may be used with any electronic component configured with hardware, software and / or firmware for exchanging information (e.g., control information) and / or data with a network. Therefore, the UE described herein is used to represent any suitable electronic device.

[0020] The exemplary embodiments will be described with reference to an exemplary network that is a 5G New Radio (5G NR) network. However, it will be appreciated that the exemplary embodiments may be implemented in any network that allows MA. In addition, because the exemplary network is described as a 5G NR network, various exemplary scenarios will be described using 5G NR terminology. For example, reference may be made to concepts such as Access Traffic Steering, Switching, and Splitting (ATSSS), Access and Mobility Management Function (AMF), UE Mobility Management (MM) Core Network Capability Information, and Multiple Access Protocol Data Unit (MA-PDU). However, it will be appreciated that different networks or entities may refer to similar concepts by different names.

[0021] Those skilled in the art will appreciate that ATSSS is a feature that enables a multi-access PDU connectivity service that can exchange data between the UE and the core network by using access networks simultaneously. The PDU connectivity service is implemented by establishing an MA-PDU session (e.g., a PDU session that can have user plane resources on two or more access networks). The ATSSS feature may not be supported by every UE. On the network side, ATSSS may not be supported by every AMF and / or supported within every registration area. Some exemplary embodiments involve the UE and the network exchanging ASSSS capability information during network registration. This allows the UE and the network to consider whether the MA-PDU session is supported when configuring a network connection for the UE.

[0022] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is shown. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will appreciate that the UE 110 may be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a desktop computer, a smart phone, a phablet, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. It should also be appreciated that an actual network arrangement may include any number of UEs used by any number of users. Therefore, for purposes of illustration, only an example with a single UE 110 is provided.

[0023] UE 110 may be configured to communicate with one or more networks. In the example of network configuration 100, the networks with which UE 110 may wirelessly communicate are 5G New Radio (NR) Radio Access Network (5G NR-RAN) 120 and Wireless Local Access Network (WLAN) 122. However, it should be understood that UE 110 may also communicate with other types of networks, and UE 110 may also communicate with a network via a wired connection. Thus, UE 110 may include a 5G NR chipset for communicating with 5G NR-RAN 120 and an ISM chipset for communicating with WLAN 122.

[0024] 5G NR-RAN 120 may be part of a cellular network that may be deployed by a cellular provider (e.g., Verizon, AT&T, T-Mobile, etc.). Network 120 may include, for example, cells or base stations (NodeB, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to send and receive traffic from UEs equipped with appropriate cellular chipsets. WLAN 122 may include any type of wireless local area network (WiFi, hotspot, IEEE802.11x network, etc.).

[0025] UE 110 may connect to 5G NR-RAN via gNB 120A. Those skilled in the art will appreciate that any relevant process may be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 may be associated with a particular cellular provider, where UE 110 and / or its user has protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 may transmit corresponding credential information in order to associate with 5G NR-RAN 120. More specifically, UE 110 may be associated with a particular base station (e.g., gNB 120A of 5G NR-RAN 120). Reference to 5G NR-RAN 120 is provided for illustrative purposes, and any type of network may be used. For example, UE 110 may also be connected to an LTE RAN (not shown) or a traditional RAN (not shown).

[0026] In addition to networks 120 and 122, network arrangement 100 includes cellular core network 130, Internet 140, IP multimedia subsystem (IMS) 150, and network service backbone 160. Cellular core network 130 can be viewed as an interconnected collection of components that manage the operation and traffic of a cellular network. Cellular core network 130 also manages traffic flowing between the cellular network and Internet 140. IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using IP protocols. IMS 150 can communicate with cellular core network 130 and Internet 140 to provide multimedia services to UE 110. Network service backbone 160 communicates directly or indirectly with Internet 140 and cellular core network 130. Network service backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality of UE 110 to communicate with various networks.

[0027] The cellular core network 130 may include a session management function (SMF) 170. The SMF 170 may be a component responsible for creating, updating, and removing protocol data unit (PDU) sessions (including MA-PDUs). The cellular core network 130 may also include an access and mobility management function (AMF) 180. The AMF 180 may be a component that communicates with the UE 110 during network registration, receives PDU requests, and forwards session management requirements to the SMF 170. To provide a general example of MA-PDU signaling, the UE 110 may transmit the MA-PDU to the AMF 180 via the gNB 120A through the 5G NR-RAN 120, or via the N3IWF through the WLAN 122. The MA-PDU may be routed to the AMF 180, which then forwards the MA-PDU to the appropriate SMF (e.g., SMF 170) to act on the request. The SMF 170 and AMF 180 shown as part of the cellular core network 130 are exemplary only, as the functionality may also reside in the 5G NR-RAN 120. In addition, those skilled in the art will appreciate that the functionality of the SMF 170 and AMF 180 may be spread throughout the cellular network, and the functionality may vary between different locations within the cellular network. Those skilled in the art will also appreciate that a network may include multiple instances of AMF and SMF, and therefore reference to a single SMF 170 and AMF 180 is for illustrative purposes only.

[0028] The request for an MA session (in the form of an MA-PDU) may be accepted or rejected by the 5G NR-RAN 120. When the request is accepted, the SMF 170 may establish an MA session for the UE 110. When the request is rejected, the SMF 170 will typically establish an SA session for the UE 110. The rejection reason may be transmitted to the UE 110, or the UE 110 may understand that the request is rejected because it has been established in an SA session rather than an MA session. In one example, the UE 110 may receive a message from the SMF 170 as a rejection, such as a PDU session establishment rejection. In another example, the UE may receive a message from the SMF 170 as an acceptance, such as a PDU session establishment acceptance, but the acceptance is for the SA session as an implicit rejection of the MA session.

[0029] There may be many reasons for rejection. For example, the SMF 170 or AMF 180 may not support the MA-PDU. In another example, the Single Network Segment Selection Assistance Information (S-NSSAI) may not be allowed on both the MA and SA. In yet another example, there may be a Policy Control Function (PCF) that blocks the MA based on the network provider's policy or the user's subscription data.

[0030] The examples of MA-PDU rejection reasons provided above are not only reasons for MA-PDU rejection, but also serve to illustrate the fact that different rejection reasons may result in different ways for the UE 110 to operate with respect to re-requesting an MA session from the network. For example, the reasons related to S-NSSAI or PCF provided above may illustrate exemplary reasons why the UE 110 may never have its MA-PDU accepted by the PLMN. Therefore, if the MA-PDU is rejected for this type of reason, the UE 110 may be prevented from re-requesting the MA-PDU within the system PLMN because it will likely waste resources of both the PLMN and the UE 110. On the other hand, the rejection reasons associated with the SMF 170 or AMF 180 that does not support the MA-PDU may change as the UE 110 moves to different registration areas of the network. For example, a provider network (e.g., a public land mobile network (PLMN)) may support MA in one area and not support MA in another area. Thus, if the MA-PDU is rejected for this type of reason, when UE 110 moves to a new registration area, UE 110 may re-request the MA-PDU because there is a chance that the MA-PDU will be accepted in the new registration area.

[0031] Some example embodiments involve the network and UE 110 exchanging MA-related capability information. Other example embodiments may involve determining when the UE should re-request an MA session after the network previously rejected the session and the manner in which the re-request is triggered.

[0032] Figure 2 An exemplary UE 110 is shown according to various exemplary embodiments. Figure 1 100 is used to describe the UE 110. The UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, an antenna panel 230, and other components 235. The other components 235 may include, for example, a SIM card, an embedded SIM (eSIM), an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting the UE 110 to other electronic devices, and the like.

[0033] Processor 205 may be configured to execute multiple engines of UE 110. For example, the engines may include MA session SMS engine 235 and ATSSS capability engine 240. MA session engine 235 may manage when UE 110 requests an MA session after a previous request has been rejected. ATSSS capability engine 240 may manage the transmission of ATSSS capability information to the network and trigger appropriate responses to ATSSS capability information received from the network.

[0034] The above engines are each an application (e.g., a program) executed by the processor 205 for exemplary purposes only. The functions associated with the engine may also be represented as an independent combined component of the UE 110, or may be a modular component coupled to the UE 110, for example, an integrated circuit with or without firmware. For example, an integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing the signal and other information. The engine may also be embodied as an application or multiple separate applications. In addition, in some UEs, the functionality described for the processor 205 is shared between two or more processors such as a baseband processor and an application processor. The exemplary embodiments may be implemented in any of these or other configurations of the UE.

[0035] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to display data to a user, and the I / O device 220 may be a hardware component that enables user input. The display device 215 and the I / O device 220 may be separate components or may be integrated together (such as a touch screen). The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120, the WLAN 122, etc. Thus, the transceiver 225 may operate on multiple different frequencies or channels (e.g., a continuous frequency group).

[0036] First, various exemplary embodiments related to determining when a UE requests an MA session with a network (after the network has previously rejected such a request) will be described below. Specifically, Figure 3 and Figure 4 Exemplary IEs that may be included during the PDU session establishment procedure will be shown. Figure 5 An exemplary method for triggering UE 110 to retry establishing an MA session will be shown, and Figure 6 An exemplary signaling diagram will be shown, which illustrates a network triggering a retry of establishing an MA session. Figures 7 to 9 Various example embodiments are described related to exchanging ATSSS information during network registration.

[0037] In an exemplary embodiment, the PDU session establishment rejection message or the PDU session establishment acceptance message received by UE 110 when the MA session has been rejected may include an indicator as to whether UE 110 is allowed to retry the MA-PDU when UE 110 moves to a different registration area of ​​the same PLMN. As will be appreciated by those skilled in the art, since UE 110 receives the indicator from the network in response to the MA-PDU, the network (e.g., AMF 180, SMF 170) determines whether UE 110 is allowed to retry the MA-PDU. The message may be configured to include an IE indicating whether the retry is allowed. Referring to FIG. Figure 3 A portion of an exemplary IE is described. UE 110 may use this indication to determine whether the UE should retry the MA-PDU when it moves to a new registration area of ​​the PLMN. Those skilled in the art will appreciate that UE 110 may move to a new registration area of ​​a different PLMN that is equivalent to the current PLMN, and the retry indicator may be valid for the equivalent PLMN as well as the current PLMN.

[0038] Figure 3 An exemplary IE 300 that may be included in a PDU session establishment rejection message or a PDU session establishment acceptance message according to various exemplary embodiments is shown. IE 300 is shown as including 3 octets and including multiple parts. However, IE 300 is not intended to limit the exemplary embodiments in any way. The actual IE may be any appropriate length, include more or less information and transmit its content in any appropriate manner.

[0039] IE 300 may be a "Retry Indicator" IE currently defined in 3GPP TS24.501. However, other currently existing one or more IEs defined in the future may include a MA-PDU retry indication. IE 300 includes bit 3 of octet 3 marked as spare. This bit may be used as a MA-PDU retry indication. For example, if the bit is set to a value of 0, this may indicate to UE 110 that MA-PDU should not be attempted when UE 110 enters a new registration area of ​​PLMN. On the other hand, if the bit is set to a value of 1, this may indicate to UE 110 that MA-PDU may be attempted when UE 110 enters a new registration area of ​​PLMN. IE 300 also includes additional spare bits in octet 3. Any of these spare bits may be used as a MA-PDU retry indication.

[0040] In another exemplary embodiment, the PDU session establishment rejection message or the PDU session establishment acceptance message received by the UE 110 when the MA session has been rejected may include a list of registration areas in the PLMN that support MA. In this way, once the UE 110 has a list of registration areas in the PLMN that support MA, the UE 110 can determine whether the new registration area is included in the list when moving to the new registration area. If the new registration area is included in the list, the UE 110 may retry the MA-PDU. If the new registration area is not included in the list, the UE 110 may skip retrying the MA-PDU when entering the new registration area. Similarly, similar to the exemplary indication provided above, since the UE 110 receives a list of registration areas from the network in response to the MA-PDU, the network (e.g., 5G NR-RAN 120) determines whether the UE 110 should retry the MA-PDU. The message may again be configured to include an information element (IE) that includes a list of registration areas. Refer to the following Figure 4 A portion of an exemplary IE is described.

[0041] Figure 4 A second exemplary IE 400 is shown that may be included in a PDU session establishment rejection message or a PDU session establishment acceptance message according to various exemplary embodiments. IE 400 is shown as including a plurality of octets. However, IE 400 is not intended to limit the exemplary embodiments in any way. The actual IE may be any appropriate length, include more or less information and transmit its content in any appropriate manner.

[0042] IE 400 may be a "5GS Tracking Area Indicator" IE currently defined in 3GPP TS24.501. However, other currently existing one or more IEs defined in the future may include a list of registration areas that support MA. IE 400 includes octets 3 to N that may be used to provide UE 110 with a list of registration areas that support MA. For example, if UE 110 moves into a registration area listed in octet 3 of IE 400, this may indicate to UE 110 that MA-PDU may be attempted. On the other hand, when UE 110 enters a new registration area that is not included in the list of IE 400, this may indicate to UE 110 that MA-PDU should not be retried.

[0043] In the above examples of IE 300 and IE 400, it is described that when UE 110 moves to a new registration area, the network (e.g., AMF 180, SMF 170) determines whether UE 110 should retry MA-PDU. However, while the network is making the determination, UE 110 may be a component that triggers a retry. For example, UE 110 may read IE 300 or IE 400 when moving to a new registration area, and if retry is allowed, UE 110 will retry establishing an MA session by transmitting MA-PDU to 5G NR-RAN 120. Therefore, in this example, 5G NR-RAN determines when a retry should be made and UE 110 triggers a retry.

[0044] Figure 5 A method 500 for a UE to trigger a retry of establishing an MA session according to various exemplary embodiments is shown. Figure 1 The network layout of 100 and Figure 2 The method 500 is described with reference to the UE 110 of FIG.

[0045] In 505, the UE 110 transmits a request for an MA session (e.g., an MA-PDU) to the 5G NR-RAN 120 via the gNB 120A. The 5G-NR RAN 120 (and the core network 130) processes the request and accepts or rejects the request. In 510, it is determined whether the MA-PDU has been accepted. If accepted, the method proceeds to 515, where the MA session is established and the method 500 ends. If rejected, in 520, the 5G NR-RAN 120 will send a rejection message to the UE 110. As described above, the rejection message may include a PDU session establishment rejection message or a PDU session establishment acceptance message. Similarly, if the acceptance indicates that an SA session will be established instead of the requested MA session, the PDU session establishment acceptance message is an implicit rejection.

[0046] In 525, the UE 110 moves to the new registration area. As described above, in this example, if a retry is allowed, the UE 110 will trigger a retry. In 530, the UE 110 will determine whether the rejection message includes a list of registration areas of the PLMN that support MA. If the registration list is not included in the rejection message, the method continues to 535 to determine whether the MA-PDU is allowed to be retried. For example, the bit in IE 300 is set so that a retry is allowed. If a retry is allowed, the method continues to 540, where the UE 110 transmits the MA-PDU to the 5G NR-RAN 120 to attempt to establish an MA session, and the method ends. If a retry is not allowed, the method ends without attempting the MA-PDU.

[0047] Returning to 530, if the registration list is included in the rejection message (e.g., IE 400 is included in the rejection message), the method continues to 545 to determine whether the new registration area is included in the list. If the new registration area is included in the registration list (e.g., it is a registration area that supports MA), the method continues to 540, where UE 110 transmits an MA-PDU to 5G NR-RAN 120 to attempt to establish an MA session, and the method ends. If the new registration area is not included in the list, the method ends without attempting an MA-PDU. Those skilled in the art will appreciate that operations associated with 530-545 may be performed each time the UE moves to a new registration area.

[0048] Figure 6 An exemplary signaling diagram 600 showing the network 120 triggering a retry of establishing an MA session according to various exemplary embodiments is shown. In this exemplary embodiment, the network (e.g., 5G NR-RAN 120) may trigger a retry of establishing an MA session. In this example, the signaling diagram 600 shows a series of messages exchanged by the UE 110 and the SMF 170 and / or AMF 180. As described above, the functions associated with the SMF 170 and / or AMF 180 may be distributed throughout the PLMN, including in the 5G NR-RAN 120 and / or the core network 130.

[0049] UE 110 transmits MA-PDU 610 to SMF 170 / AMF 180 to attempt to establish an MA session. In this example, it can be considered that SMF 170 / AMF 180 rejects the request. However, when UE 110 moves to a new registration area of ​​PLMN, the rejection can be considered to be of a type that should allow UE 110 to retry to establish an MA session. Therefore, SMF 170 / AMF 180 sends a rejection message 620, which includes an indication that MA-PDU retry is allowed when UE 110 moves to a new registration area, for example, the rejection message 620 includes IE 300 with a bit set to allow MA-PDU retry.

[0050] UE 110 then moves 630 to the new registration area. In response to the move 630, the UE sends a registration request 640 to SMF 170 / AMF 180. As part of the registration request 640, UE 110 may include an indication (e.g., IE 300) that allows UE 110 to retry establishing an MA session when moving to the new registration area. When SMF 170 / AMF 180 receives the registration request 640 including an indication that allows UE 110 to retry establishing an MA session when moving to the new registration area, SMF 170 / AMF 180 may send a PDU session modification command 650 to change the UE 110 session from an SA session to an MA session. Those skilled in the art will appreciate that if the new registration area supports MA, the PDU session modification command 650 will be sent. Therefore, in this way, the retry of establishing an MA session is triggered by the network rather than UE 110.

[0051] In another exemplary embodiment, the UE 110 may track the registration areas in which MA sessions have been established in the past. For example, when the UE 110 has established an MA session with the 5G NR-RAN 120, the UE 110 may record the registration areas in which the MA session has been established, for example by creating a list and storing the list in the memory arrangement 210 of the UE 110.

[0052] When the MA-PDU request of UE 110 has been rejected and UE 110 subsequently moves into a new registration area, UE 110 may check the stored list of registration areas in memory arrangement 210. If the new registration area is included in the list, UE 110 may retry to establish an MA session by transmitting an MA-PDU to the network. UE 110 may also store a corresponding list of registration areas in which the MA-PDU has been rejected, and when entering a registration area of ​​that type, UE 110 may avoid retrying the MA-PDU.

[0053] In another exemplary embodiment, UE 110 may retry establishing an MA session when moving to a new registration area based on the type of application data exchanged with the network. For example, if the application data uses a high reliability and / or high throughput connection, UE 110 may retry establishing an MA session when moving to a new registration area because the MA session may achieve the reliability and / or throughput requirements of the application data. Examples of these types of application data may include voice recognition application data that typically uses a high reliability connection, or multimedia data that typically uses a high throughput connection. On the other hand, there may be types of application data that do not use a high reliability and / or high throughput connection, and therefore UE 110 may not retry establishing an MA session when using these types of application data. Examples of such application data may be background application data traffic.

[0054] The above exemplary embodiments relate to establishing an MA session. The following exemplary embodiments relate to UE 110 and the network exchanging ATSSS capability information. ATSSS capability information may be exchanged during network registration and before UE 110 and the network attempt to establish an MA session. As will be described below, in some exemplary embodiments, the ATSSS capability information may provide a basis for UE 110 to determine not to establish a PDU session.

[0055] Figure 7 A signaling diagram 700 related to UE 110 providing ASSS capability information to AMF 180 according to various exemplary embodiments is shown.

[0056] First, consider the following example scenario. UE 110 is camped on gNB 120A. In order to receive the full range of functions that are usually available via a network connection, UE 110 may register with the network. A registration procedure may be performed between UE 110 and AMF 180.

[0057] In 705, a registration procedure is initiated between the UE 110 and the AMF 180. Those skilled in the art will appreciate that the exemplary embodiments are applicable to any suitable type of registration procedure (e.g., an attach procedure, an initial registration procedure, a mobility registration update procedure, etc.).

[0058] In 710, UE 110 may transmit an indication to AMF 180 indicating whether UE 110 is configured with ASSS capability. In some embodiments, UE 110 may include the indication in UE MM core network capability information. Those skilled in the art will understand the format of the UE MM core network capability information message and when the message may be transmitted to the network during the registration procedure. However, it should be clear that ASSS capability information may be sent by UE 110 in any type of message at any time during the registration procedure. In this example, UE 110 supports ASSSS functionality.

[0059] The AMF may be configured with an AMF selection function. For example, if the first AMF is not an appropriate AMF for serving UE 110, the first AMF may select a different second AMF to serve UE 110. If UE 110 supports ATSSS and the first AMF does not support ASSS, the AMF may not be an appropriate AMF for serving UE 110. In this example, AMF 180 is configured with an AMF selection function and is not configured with an ASSS function.

[0060] In 715, the AMF 180 selects an additional AMF to serve the UE 110. As indicated above, in this example, the UE 110 supports the ATSSS functionality, and the AMF 180 does not support the ASSSS functionality. Therefore, the AMF 180 selects an additional AMF configured with ATSSS to serve the UE 110. Subsequently, additional signaling is exchanged between the UE 110 and the network to complete the registration procedure (not shown).

[0061] Figure 8 A signaling diagram 800 related to AMF 180 providing ASSS capability information to UE 110 according to various exemplary embodiments is shown.

[0062] In 805, a registration procedure is initiated between the UE 110 and the AMF 180. Those skilled in the art will appreciate that the exemplary embodiments are applicable to any suitable type of registration procedure (e.g., an attach procedure, an initial registration procedure, a mobility registration update procedure, etc.).

[0063] In 810, AMF 180 may transmit an indication indicating whether the registration area supports ASSS functionality to UE 110. The indication may be provided to UE 110 at any suitable point during the registration procedure and in any suitable format.

[0064] In 815, the registration procedure may be completed. When the AMF 180 indicates that ATSSS is not supported in the registration area, the UE 110 may omit transmitting various types of requests when deployed in the registration area to avoid creating multiple PDU sessions with the same PDU session ID. To provide an example, the UE 110 may not i) request to establish an MA PDU session, ii) request to add user plane resources for an existing MAPDU session, iii) request to establish a PDU session via an "MA PDU Network Update Permit Indication", iv) request a PDU session modification with a request type of "MA PDU Request", and / or v) request a PDU session modification with a request type of "MA PDU Network Update Permit" indication after moving from an Evolved Packet Core (EPC) to a 5G Core (5GC). Therefore, based on receiving an indication that ATSSS is not supported in the registration area, the UE 110 may omit sending these types of requests, despite their normal triggering conditions occurring.

[0065] Fig. 9 A signaling diagram 900 related to AMF 180 providing ASSS capability information to UE 110 according to various exemplary embodiments is shown.

[0066] In 905, a registration procedure is initiated between the UE 110 and the AMF 180. Those skilled in the art will appreciate that the exemplary embodiments are applicable to any suitable type of registration procedure (e.g., an attach procedure, an initial registration procedure, a mobility registration update procedure, etc.).

[0067] In 910, AMF 180 may transmit an indication to UE 110 indicating whether ASSS is supported throughout the PLMN. The indication may be provided to UE 110 at any suitable point during the registration procedure and in any suitable format.

[0068] A PLMN may or may not have uniform support of ATSSS across all its registration areas. If ATSSS is not supported in the entire PLMN, the UE 110 will be informed of this condition to determine whether to reselect to another PLMN if the UE 110 wants to utilize the ATSSS function while roaming. In this example, ATSSS is not supported in the entire registration area.

[0069] For example, consider the scenario described above with respect to signaling diagram 800. In 810, UE 110 receives an indication that ATSSS is not supported in the registration area. Without the indication provided in 910, UE 110 would not know whether UE 110 should reselect to another PLMN or whether another registration area in the currently serving PLMN supports ATSSS. Therefore, the indication provided in 910 allows UE 110 to make an informed decision regarding PLMN reselection.

[0070] Returning to signaling diagram 900, at 915, the registration procedure may be completed. At 920, UE 110 determines to utilize ATSSS functionality. At 925, UE 110 performs PLMN reselection.

[0071] Those skilled in the art will appreciate that the above examples of application data types are provided for illustrative purposes only. There may be other types of application data that may or may not trigger an MA-PDU attempt. As described above, the trigger may be based on a predetermined reliability or throughput of the application data. In another example, different types of application data may be defined with corresponding MA-PDU trigger characteristics.

[0072] In addition, the exemplary embodiments are described with reference to AMF. In other exemplary embodiments, the functions described herein for AMF may also be performed by a mobility management entity (MME).

[0073] Although this patent application describes various combinations of various aspects, each with different features, those skilled in the art will understand that any feature of one aspect may be combined with features of other aspects or features that are not functionally or logically inconsistent with the operation or function of the device of the aspects disclosed in the present invention in any manner not publicly denied.

[0074] Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented with any suitable software configuration or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, etc. In other examples, the exemplary embodiments of the above methods may be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, may be executed on a processor or microprocessor.

[0075] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0076] It will be apparent to those skilled in the art that various modifications may be made to the present disclosure without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is intended to cover modifications and variations of the present disclosure, provided that these modifications and variations are within the scope of the appended claims and their equivalents.

[0077] Priority Claim / Incorporation by Reference

[0078] This patent application claims priority to U.S. Provisional Application Serial No. 62 / 929,420, entitled “Establishing a Multiple Access Connection,” filed on November 1, 2019, and U.S. Provisional Application Serial No. 62 / 981,486, entitled “Establishing a Multiple Access Connection,” filed on February 25, 2020, the entire contents of which are incorporated herein by reference.

Claims

1. A method comprising: At the Access and Mobility Management Function (AMF) of the cellular network: receiving, as part of a registration procedure performed with a user equipment (UE), an indication that the UE supports access traffic steering, switching and splitting (ATSSS); Determine that ATSSS is not supported; and As part of the registration procedure with this UE, an indication that ATSSS is not supported is sent.

2. The method according to claim 1, wherein: ATSSS is not supported in the registration area that the UE is attempting to register.

3. The method according to claim 1, wherein: ASSS is not supported in the Public Land Mobile Network (PLMN) with which the UE is attempting to register.

4. The method according to claim 1, wherein: The registration procedure includes an attach procedure, an initial registration procedure or a mobility registration update procedure.

5. An apparatus comprising a processing circuit, the processing circuit being configured to: Perform registration procedures with the Access and Mobility Management Function (AMF); During the registration procedure, handle indications from the AMF that Access Traffic Steering, Switching and Splitting (ATSSS) is not supported in the registration area; determining that a triggering condition for a request associated with a multiple access (MA) packet data unit (PDU) session has been satisfied; as well as When an indication that ATSSS is not supported is received and a trigger condition is satisfied, based on the indication and the satisfaction of the trigger condition, when the UE is deployed in the registration area, generating a request related to the MA PDU session is omitted.

6. The device according to claim 5, wherein: The request is related to the establishment of a new MA PDU session.

7. The device according to claim 5, wherein: The request is related to establishing a PDU session via a MA PDU Network Update Grant indication.

8. The device according to claim 5, wherein: The request is related to a PDU session modification with a request type of MA PDU request.

9. The device according to claim 5, wherein: The request is related to a PDU session modification with a request type of MA PDU network update permission indication after moving from Evolved Packet Core (EPC) to 5G Core (5GC).

10. The device according to claim 5, wherein: The request is related to adding user plane resources for an existing MA PDU session.

11. A user equipment (UE), comprising: a transceiver circuit configured to communicate with a network; as well as a processing circuit, communicatively coupled to the transceiver circuit, and configured to: Perform registration procedures with the Access and Mobility Management Function (AMF); During the registration procedure, handle indications from the AMF that Access Traffic Steering, Switching and Splitting (ATSSS) is not supported in the registration area; determining that a triggering condition for a request associated with a multiple access (MA) packet data unit (PDU) session has been satisfied; as well as When an indication that ATSSS is not supported is received and a trigger condition is satisfied, based on the indication and the satisfaction of the trigger condition, when the UE is deployed in the registration area, generating a request related to the MA PDU session is omitted.

12. The UE according to claim 11, wherein: The request is related to the establishment of a new MA PDU session.

13. The UE according to claim 11, wherein: The request is related to establishing a PDU session via a MA PDU Network Update Grant indication.

14. The UE according to claim 11, wherein: The request is related to a PDU session modification with a request type of MA PDU request.

15. The UE according to claim 11, wherein: The request is related to a PDU session modification with a request type of MA PDU network update permission indication after moving from Evolved Packet Core (EPC) to 5G Core (5GC).

16. The UE according to claim 11, wherein: The request is related to adding user plane resources for an existing MA PDU session.

Images