Patent Description:
The choice of the identity to indicate to the network is specified in the Third Generation Partnership Project (3GPP) Technical Standard (TS) <NUM>, clause <NUM>. <NUM> as follows. When the UE is performing an Initial Registration, the UE shall indicate its UE identity in the Registration Request message as follows, listed in decreasing order of preference:.

There is one scenario, however, where this simple logic for selection of a <NUM>-GUTI can lead to an error situation. Specifically, consider the following case:.

The current specification does not allow for such an option. According to the current specification text AMF1 will return the entire UE context, which will eventually lead to an error situation where the Protocol Data Unit (PDU) Sessions established over access type <NUM> will be disrupted.

While this problem has been described in the context of Initial Registration, it also exists in the context of Mobility Registration Update when the latter procedure is performed as part of the mobility procedure for UE returning from an Evolved Packet System (EPS) to the <NUM> System, for example as described in 3GPP TS <NUM> clause <NUM>. <NUM> (step <NUM>) and 3GPP TS <NUM> clause <NUM>. <NUM> (step <NUM>).

The following documents are relevant: 3GPP DRAFT; C1-<NUM>-DISC; <NPL>; <CIT> which discusses a method for transmitting and receiving signal related to switching access in wireless communication system and device therefor.

Claimed subject matter is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when read with the accompanying drawings in which:.

It will be appreciated that for simplicity and/or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of claimed subject matter. It will, however, be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and/or circuits have not been described in detail.

In the following description and/or claims, the terms coupled and/or connected, along with their derivatives, may be used. In particular embodiments, connected may be used to indicate that two or more elements are in direct physical and/or electrical contact with each other. Coupled may mean that two or more elements are in direct physical and/or electrical contact. However, coupled may also mean that two or more elements may not be in direct contact with each other, but yet may still cooperate and/or interact with each other. For example, "coupled" may mean that two or more elements do not contact each other but are indirectly joined together via another element or intermediate elements. Finally, the terms "on," "overlying," and "over" may be used in the following description and claims. "On," "overlying," and "over" may be used to indicate that two or more elements are in direct physical contact with each other. It should be noted, however, that "over" may also mean that two or more elements are not in direct contact with each other. For example, "over" may mean that one element is above another element but not contact each other and may have another element or elements in between the two elements. Furthermore, the term "and/or" may mean "and", it may mean "or", it may mean "exclusive-or", it may mean "one", it may mean "some, but not all", it may mean "neither", and/or it may mean "both", although the scope of claimed subject matter is not limited in this respect. In the following description and/or claims, the terms "comprise" and "include," along with their derivatives, may be used and are intended as synonyms for each other.

Referring now to <FIG>, a diagram of non-roaming architecture for a Fifth Generation (<NUM>) Core Network for a user equipment (UE) with an untrusted non-3GPP access network, which typically can be a wireless local area network (WLAN) such as a Wi-Fi network, and a Next Generation Radio Access Network (NG RAN) in accordance with one or more embodiments will be discussed. <FIG> shows an example architecture <NUM> in which a UE <NUM> can connect to the network via Third Generation Partnership Project (3GPP) Access <NUM> or via untrusted non-3GPP access <NUM>. In some examples, the untrusted non-3GPP access network <NUM> can be a wireless local area network (WLAN) network. In some examples, the untrusted non-3GPP access network <NUM> can be connected to a <NUM> core network through an N3 interface interworking function (N3IWF) <NUM>. Architecture <NUM> can include Access Management Function (AMF) <NUM>, Session management Function (SMF) <NUM>, and User Plane Function (UPF) <NUM> to connect to Data Network <NUM>. It should be noted that architecture <NUM> of <FIG> illustrates one example of a UE that can connect to a core network either via 3GPP Access <NUM> or untrusted non-3GPP access <NUM> via N3IWF <NUM>, or both, and the scope of the claimed subject matter is not limited in this respect.

In accordance with one or more embodiments, a UE context transfer may be implemented wherein a new AMF requests a UE context transfer from the old AMF. When this occurs, the new AMF can indicate the Access Type in the UE Context Transfer request. The Access Type, in combination with the Public Land Mobile Network (PLMN) identity of the new AMF, allows the old AMF to determine whether it is possible to relocate the N2 interface on the new AMF or not. In the latter case the old AMF only provides UE's Subscription Permanent Identifier (SUPI) with an indication that the Registration Request has been validated for integrity protection. Otherwise, the old AMF will provide the whole UE context to the new AMF and will eventually release the protocol data unit (PDU) Sessions established over the first access. This issue can be addressed as shown in and described with respect to <FIG>, below.

<FIG> is a diagram of registration procedure in accordance with one or more embodiments. Registration procedure <NUM> of <FIG> illustrates a modification of the call flow as described in Third Generation Partnership Project (3GPP) Technical Specification (TS) <NUM> clause <NUM>. <NUM> (General Registration). The modification is directed to operation <NUM> (Namf_Communication_UEContextTransfer) and operation <NUM> (Namf_Communication_UEContextTransfer response) of the registration procedure. It should be noted that where the standard is references, below, modifications or additions to the standard are indicated by underlined text. In general, <FIG> shows the registration procedure operations executed by user equipment (UE) <NUM>, access network or radio access network (RAN) <NUM>, the new Access and Mobility Function (AMF) <NUM>, old AMF <NUM>, Policy Control Function (PCF) <NUM>, Session Management Function (SMF) <NUM>, Authentication Server Function (ASF) <NUM>, and Unified Data Management (UDM) <NUM>.

In one or more embodiments, when the new AMF <NUM> requests UE context transfer from the old AMF <NUM>, the new AMF <NUM> indicates the Access Type in the UE Context Transfer request. The Access Type, in combination with the PLMN identity of the new AMF <NUM>, allows the old AMF <NUM> to determine whether it is possible to relocate the N2 interface on the new AMF 214or not. In the latter case the old AMF <NUM> only provides the UE's <NUM> SUPI with an indication that the Registration Request has been validated for integrity protection. Alternatively, the old AMF <NUM> simply rejects the UE context transfer request. This will lead the new AMF <NUM> to request the UE identity over the air using the Identity Request procedure.

The logic in the old AMF for determining whether the N2 interface can be relocated to the new AMF can be described with the following algorithm:
<IMG>.

Messaging from the new AMF <NUM> to the old AMF <NUM> can involve transmission of a Namf_Communication_UEContextTransfer message which includes a complete Registration Request, or from the new AMF <NUM> to the UDSF can involve transmission of a Nudsf Unstructured Data Management_Query() message. With Unstructured Data Storage Function (UDSF) Deployment, if the UE's <NUM>-GUTI was included in the Registration Request and the serving AMF has changed since the last Registration procedure, the new AMF <NUM> and the old AMF are in the same AMF Set and UDSF is deployed, the new AMF <NUM> retrieves the stored UE's SUPI and UE context directly from the UDSF using the Nudsf_UnstructuredDataManagement_Query service operation or they can share stored UE context via implementation specific means if UDSF is not deployed. This includes also event subscription information by each NF consumer for the given UE. In this case, the new AMF <NUM> uses integrity protected complete Registration request Non-Access Stratum (NAS) message to perform and verify integrity protection.

Without UDSF Deployment, if the UE's <NUM>-GUTI was included in the Registration Request and the serving AMF has changed since last Registration procedure, the new AMF may invoke the Namf_Communication_UEContextTransfer service operation on the old AMF <NUM> including the complete Registration Request NAS message, which may be integrity protected, as well as the Access Type, to request the UE's SUPI and UE Context. See 3GPP TS <NUM> clause <NUM>. <NUM> for details of this service operation. In this case, the old AMF <NUM> uses either <NUM>-GUTI and the integrity protected complete Registration request NAS message, or the SUPI and an indication that the UE <NUM> is validated from the new AMF <NUM>, to verify integrity protection if the context transfer service operation invocation corresponds to the UE <NUM> requested. The old AMF <NUM> also transfers the event subscriptions information by each NF consumer, for the UE <NUM>, to the new AMF <NUM>.

In one or more embodiments, if the old AMF <NUM> has PDU Sessions for another access type, different from the Access Type indicated in this operation, and if the old AMF <NUM> determines that there is no possibility for relocating the N2 interface to the new AMF <NUM>, the old AMF <NUM> returns UE's SUPI and indicates that the Registration Request has been successfully validated for integrity protection, but does not include the rest of the UE context.

Alternatively, if the old AMF <NUM> has PDU Sessions for another access type, different from the Access Type indicated in this operation, and if the old AMF <NUM> determines that there is no possibility for relocating the N2 interface to the new AMF <NUM>, the old AMF <NUM> rejects the UE context transfer request. In case of rejection, the new AMF <NUM> uses the Identity Request message (operation <NUM>) to request UE's identity.

NOTE <NUM>: The new AMF sets the indication that the UE is validated according to step 9a, in case the new AMF has performed successful UE authentication after previous integrity check failure in the old AMF.

NOTE <NUM>: The NF consumers does not need to subscribe for the events once again with the new AMF after the UE is successfully registered with the new AMF.

If the new AMF <NUM> has already received UE contexts from the old AMF <NUM> during handover procedure, then operation <NUM>, operation <NUM>, and operation <NUM> can be skipped.

For an Emergency Registration, if the UE <NUM> identifies itself with a <NUM>-GUTI that is not known to the AMF, operation <NUM> and operation <NUM> can be skipped and the AMF immediately requests the SUPI from the UE <NUM>. If the UE <NUM> identifies itself with PEI, the SUPI request shall be skipped. Allowing Emergency Registration without a user identity is dependent on local regulations.

Messaging from the old AMF <NUM> to the new AMF <NUM> can involve transmission of the Response to Namf_Communication_UEContextTransfer (SUPI, UE Context in AMF as per Table <NUM>. <NUM>-<NUM>)) or from the UDSF to the new AMF <NUM> or the Nudsf_Unstructured Data Management_Query(). The old AMF <NUM> may start an implementation specific (guard) timer for the UE context. The UE Context in AMF (as per Table <NUM>. <NUM>-<NUM>) is not included in the response if the old AMF <NUM> determines that there is no possibility for relocation of the N2 interface.

If the UDSF was queried in operation <NUM>, the UDSF responds to the new AMF <NUM> for the Nudsf Unstructured Data Management_Query invocation with the related contexts including established PDU Sessions, the old AMF <NUM> includes SMF information DNN, S-NSSAI(s) and PDU Session ID, active NGAP UE-TNLA bindings to N3IWF, the old AMF <NUM> includes information about the NGAP UE-TNLA bindings. If the old AMF <NUM> was queried in operation <NUM>, the old AMF <NUM> responds to the new AMF <NUM> for the Namf_Communication_UEContextTransfer invocation by including the UE's SUPI and UE Context.

If the old AMF <NUM> holds information about established PDU Session(s), the old AMF <NUM> includes SMF information, DNN(s), S-NSSAI(s) and PDU Session ID(s).

If the old AMF <NUM> holds information about active NGAP UE-TNLA bindings to N3IWF, the old AMF <NUM> includes information about the NGAP UE-TNLA bindings.

If the old AMF <NUM> fails the integrity check of the Registration Request NAS message, the old AMF <NUM> shall indicate the integrity check failure.

If the old AMF <NUM> holds information about AM Policy Association, the old AMF includes the information about the Access and Mobility (AM) Policy Association including the policy control request trigger and PCF ID. In the roaming case, V-PCF ID and H-PCF ID are included.

In one or more embodiments, the definition of the UE ContextTransfer service in 3GPP TS <NUM> clause <NUM>. <NUM> can be updated accordingly, as follows.

See clause <NUM>. <NUM> for example of usage of this service operation. If the consumer NF sent an integrity protected message from the UE, the AMF uses it to verify whether this request is permitted to retrieve the UE context of the UE. If it is permitted, the AMF provides UE context to the consumer NF in the Namf_Communication_UEContextTransfer response. The following table illustrates the UE Context:.

There is also the addition of "accessType" and "plmnId" (of the target AMF which is the new AMF <NUM>) in 3GPP TS <NUM> in clause <NUM>. <NUM> Type: UeContextTransferReqData as shown in Table <NUM>. <NUM>-<NUM> below.

<FIG> illustrates an architecture of a system <NUM> of a network in accordance with some embodiments. The system <NUM> is shown to include a user equipment (UE) <NUM> and a UE <NUM>. The UEs <NUM> and <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the UEs <NUM> and <NUM> can comprise an Internet of Things (IoT) UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

The UEs <NUM> and <NUM> may be configured to connect, e.g., communicatively couple, with a radio access network (RAN) <NUM> - the RAN <NUM> may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs <NUM> and <NUM> utilize connections <NUM> and <NUM>, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (<NUM>) protocol, a New Radio (NR) protocol, and the like.

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

The RAN <NUM> is shown to be communicatively coupled to a core network (CN) <NUM> -via an S1 interface <NUM>. In embodiments, the CN <NUM> may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface <NUM> is split into two parts: the S1-U interface <NUM>, which carries traffic data between the RAN nodes <NUM> and <NUM> and the serving gateway (S-GW) <NUM>, and the S1-mobility management entity (MME) interface <NUM>, which is a signaling interface between the RAN nodes <NUM> and <NUM> and MMEs <NUM>.

<FIG> illustrates example components of a device <NUM> in accordance with some embodiments. In some embodiments, the device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, one or more antennas <NUM>, and power management circuitry (PMC) <NUM> coupled together at least as shown. The components of the illustrated device <NUM> may be included in a UE or a RAN node. In some embodiments, the device <NUM> may include less elements (e.g., a RAN node may not utilize application circuitry <NUM>, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The baseband circuitry <NUM> may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a third generation (<NUM>) baseband processor 404A, a fourth generation (<NUM>) baseband processor 404B, a fifth generation (<NUM>) baseband processor 404C, or other baseband processor(s) 404D for other existing generations, generations in development or to be developed in the future (e.g., second generation (<NUM>), sixth generation (<NUM>), etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 404A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. In other embodiments, some or all of the functionality of baseband processors 404A-D may be included in modules stored in the memory <NUM> and executed via a Central Processing Unit (CPU) 404E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include one or more audio digital signal processor(s) (DSP) 404F. The audio DSP(s) 404F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the receive signal path of the RF circuitry <NUM> may include mixer circuitry 406a, amplifier circuitry 406b and filter circuitry 406c. In some embodiments, the transmit signal path of the RF circuitry <NUM> may include filter circuitry 406c and mixer circuitry 406a. RF circuitry <NUM> may also include synthesizer circuitry 406d for synthesizing a frequency for use by the mixer circuitry 406a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 406a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 406d. The amplifier circuitry 406b may be configured to amplify the down-converted signals and the filter circuitry 406c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 406a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 406a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 406d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 406c.

In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the synthesizer circuitry 406d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 406d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 406d may be configured to synthesize an output frequency for use by the mixer circuitry 406a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 406d may be a fractional N/N+<NUM> synthesizer.

In some embodiments, frequency input may be provided by a voltage-controlled oscillator (VCO), although that is not a requirement.

Synthesizer circuitry 406d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 406d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

While <FIG> shows the PMC <NUM> coupled only with the baseband circuitry <NUM>. In other embodiments, however, the PMC <NUM><NUM> may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry <NUM>, RF circuitry <NUM>, or FEM <NUM>.

If there is no data traffic activity for an extended period of time, then the device <NUM> may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device <NUM> goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device <NUM> may not receive data in this state, in order to receive data, it must transition back to RRC_Connected state.

As referred to herein, Layer <NUM> may comprise a physical (PHY) layer of a UE/RAN node.

Claim 1:
One or more processors of an Access and Mobility Function, AMF, configured to perform operations comprising:
receiving a request from a new AMF for a user equipment, UE, context transfer for a UE registered to the AMF with a first access type, wherein the request includes an indication of a second access type for the UE to register with the new AMF; and wherein the one or more processors are characterized by being configured to perform operations comprising:
determining that an interface cannot be relocated to the new AMF; and
returning to the new AMF a subscription permanent identifier, SUPI, of the UE and an indication that a registration request procedure is validated for integrity protection without including an entire UE context in response to determining that the interface cannot be relocated to the new AMF.