Patent Description:
Systems, methods, and instrumentalities are disclosed for an access control and mobility management function (AMF) node, comprising a processor configured to receive a N2 session management (SM) information from a session management function (SMF) node, wherein the N2 SM information indicates an available area for N2 information, receive a service request from a wireless transmit receive unit (WTRU), determine whether to update the N2 SM information based on a location of the WTRU and the available area for N2 information, wherein if the WTRU is outside of the available area for N2 information, the processor is configured to request a second N2 SM information from the SMF node and update the N2 SM information with the second N2 SM information, and send an N2 request with the N2 SM information to an access network associated with the WTRU. The available area for N2 information may be one or more of a user plane function (UPF) node serving area, a WTRU tracking area, or a radio access network (RAN) cell coverage area. In the following, the invention is best understood in view of <FIG>. The remaining embodiments, aspects, or examples are included in order to help the reader better understand the invention.

A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like.

The full duplex radio may include an interference management unit <NUM> to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor <NUM>).

While each of the foregoing elements is depicted as part of the CN <NUM>, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

For example, the CN <NUM> may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN <NUM>, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.

The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU/UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like.

In view of <FIG>, and the corresponding description of <FIG>, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME <NUM>, SGW <NUM>, PGW <NUM>, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown).

Examples provided herein do not limit applicability of the subject matter to other wireless technologies, e.g., using the same or different principles as may be applicable.

An example <NUM> network may be described herein. <FIG> illustrates an example architecture for a <NUM> and/or a next generation (NextGen) network. In <FIG>, a radio access network (RAN) may refer to a radio access network based on <NUM> radio access technology (RAT) and/or Evolved E-UTRA that may connect to the NextGen core network. An access control and mobility management function (AMF) may include one or more of the following functionalities: registration management, connection management, reachability management, mobility management, and/or the like. A session management function (SMF) may include one or more of the following functionalities: session management (e.g., which may include session establishment and/or modify and release), wireless transmit/receive unit (WTRU) internet protocol (IP) address allocation, selection and control of user plane (UP) function, and/or the like. A user plane function (UPF) may include one or more of the following functionalities: packet routing and forwarding, packet inspection, traffic usage reporting, and/or the like.

UPF and/or SMF relocation may be described herein. In deployment, a <NUM> network may include one or more of UPFs and/or SMFs. Each UPF and/or SMF may serve an area (e.g., a specific area). During the WTRU's mobility, if the WTRU moves out of the current UPF and/or SMF serving area, the network may assign one or more other UPFs and/or SMFs to serve the WTRU. In some scenarios described herein, a first UPF (or SMF) may be described as an anchor UPF (or SMF), and a subsequent UPF (or SMF) (e.g., based on mobility) may be described as an intermediate UPF (or SMF).

A UPF may change (e.g., based on mobility) without a corresponding SMF change, as can be seen in <FIG> illustrates an example UPF relocation due to WTRU mobility where the UPF relocation is performed without a SMF change. Procedures for UPF relocation without SMF change may be described herein. As shown in <FIG>, a WTRU in a UPF servicing area <NUM> may establish a protocol data unit (PDU) session with a UPF-<NUM>. The WTRU may move to a UPF serving area <NUM>, where the (e.g., previous) RAN may not be able to contact the UPF-<NUM> (e.g., directly). The network may assign a UPF-<NUM> to serve the WTRU.

If the network maintains the PDU session continuity, the network may assign the UPF-<NUM> as an intermediate node and may establish a tunnel between the UPF-<NUM> and the UPF-<NUM>. One or more (e.g., all) data packets between the UPF-<NUM> and the WTRU may be forwarded by the UPF-<NUM>. The UPF that originally served the PDU session (e.g., UPF-<NUM>) may be referred to as an anchor-UPF (A-UPF), and the UPF that was assigned by the network due to WTRU mobility (e.g., UPF-<NUM>) may be referred to as an intermediate-UPF (I-UPF).

If the network does not maintain the PDU session continuity, the network may notify the WTRU to re-establish the PDU session and may assign the UPF-<NUM> as an anchor node of the new PDU session. The old PDU session (e.g., old PDU session associated with the UPF-<NUM>) may be released.

Procedures for UPF relocation with SMF change may be described herein. <FIG> illustrates an example UPF relocation due to WTRU mobility where the UPF relocation is performed with a SMF change. If the WTRU moves to a UPF serving area <NUM>, where the UPF-<NUM> is unable to be controlled by the SMF-<NUM>, the network may assign the SMF-<NUM> to control the UPF-<NUM> for the WTRU's PDU session. If the network assigns the SMF-<NUM> to control the UPF-<NUM>, a tunnel may be established between the UPF-<NUM> (e.g., I-UPF) and the UPF-<NUM> (e.g., A-UPF). One or more (e.g., all) data packets between the UPF-<NUM> (e.g., A-UPF) and the WTRU may be forwarded by the UPF-<NUM> (e.g., I-UPF). The SMF-<NUM> may be referred to as an intermediate SMF (e.g., I-SMF), which controls the I-UPF. The SMF-<NUM> may be referred to as an anchor SMF (e.g., A-SMF), which may control the A-UPF.

The AMF may communicate with an SMF, which may, in turn, communicate with a UPF. In examples where anchor and intermediate SMFs and UPFs are present, one or more architectures may be provided, for example based on the interaction between the AMF and the SMF.

<FIG> illustrates an example architecture with multiple SMFs. For example, an AMF may select and/or communicate with an I-SMF. One or more (e.g., all) session management (SM) non-access stratum (NAS) messages received from a WTRU (not depicted) may be sent to the I-SMF by the AMF. The I-SMF may cooperate with the A-SMF, e.g., to control the data plane.

<FIG> illustrates an example architecture with multiple SMFs. For example, an AMF may select and/or communicate with an A-SMF. One or more (e.g., all) SM NAS message received from a WTRU (not depicted) may be sent to the A-SMF by the AMF. The A-SMF may cooperate with the I-SMF, e.g., to control the data plane.

During a network-triggered service request, an invalid data path in the UPF relocation may occur. <FIG> illustrates an example of an invalid data path occurring in a UPF relocation due to WTRU mobility in an idle mode. For example, in a network-triggered (NW-triggered) service request procedure, an SMF may send UPF information to the current RAN via the AMF. The WTRU may perform a service request procedure (e.g., in response to being paged). Upon waking, the WTRU may enter connected mode and report its location. The SMF may re-allocate the UPF (e.g., switch to a new I-UPF from an old I-UPF). In some examples, the SMF may send N2 SM information (e.g., which may include an I-UPF tunnel information) in a N11 message to the AMF. If the SMF sends the AMF N2 SM information related to the old I-UPF (e.g., before the WTRU service request and/or before UPF re-allocation), and if the AMF sends the RAN the N2 SM information (e.g., related to the old I-UPF), the data path may be invalid (e.g., the RAN may not be able to establish a tunnel to the old I-UPF).

The numbers/elements shown in call flows may be presented for the purpose of reference. As such, the numbered actions may be performed in a different order (e.g., in whole or in part) and/or some actions may be skipped.

<FIG> illustrates an example network-triggered (NW-triggered) service request procedure. When the WTRU is in idle state (e.g., at <NUM> of <FIG>) and the I-UPF receives downlink data of the PDU session (e.g., at <NUM>), the network may initiate the NW-triggered service request procedure by paging the WTRU and/or establishing the PDU data path.

A WTRU may move out of a serving area (e.g., a serving area of the old I-UPF) when the WTRU is in idle state. If the WTRU moves out of the serving area of the old I-UPF when the WTRU is in idle state, the tunnel established in the exemplary procedures shown in <FIG> (e.g., between the RAN and the old I-UPF) may not be established correctly. For example, the tunnel established between the RAN and the old I-UPF may not be established correctly because the RAN, which is serving the WTRU, may not be able to communicate with the old I-UPF. One or more WTRU's packets may be discarded if the tunnel is not established correctly.

Signaling (e.g., extra signaling) in UPF relocation with SMF change when a WTRU is idle may occur. When a WTRU enters idle state, the data path of the PDU session between the RAN and I-UPF may be released, and the data path between the I-UPF and A-UPF may be kept. For example, in the example architecture shown in <FIG>, if the WTRU moves out of the I-SMF serving area during the WTRU mobility (e.g., to a serving area of new I-SMF (not depicted)), the AMF may select a new I-SMF, and the new I-SMF may initiate one or more N9 data path switch procedures. For example, the N9 data path switch procedure may select a new I-UPF and may update the A-UPF (e.g., the N9 tunnel information stored in the A-UPF).

The WTRU may be in idle state without a data packet. The WTRU may continue moving out of the new I-UPF service area (e.g., the N9 data path switch procedure may not be needed). One or more N9 data path switch procedures described herein may be skipped (e.g., to decrease extra unnecessary messages).

The I-SMF and/or A-SMF described in <FIG> may handle one or more different messages from/to the AMF. For example, the I-SMF may generate a N11 message for downlink data notification (e.g., since the I-UPF may be controlled by the I-SMF). The A-SMF may handle a resource request message from the AMF (e.g., since the A-SMF may be an endpoint communicating with the policy frame work and/or charging system).

An SMF (e.g., I-SMF for <FIG> architecture or A-SMF for <FIG> architecture) may communicate (e.g., directly) with the AMF. For one or more SMFs architecture shown in <FIG>, one or more (e.g., all) the resource request related messages from the AMF may (e.g., must) be passed by the I-SMF to the A-SMF. For one or more SMFs architecture shown in <FIG>, one or more (e.g., all) service request related messages from the I-SMF may (e.g., must) be passed by the A-SMF to the AMF.

UPF relocation during network-triggered service requests may be implemented.

For example, when downlink data notification is received from a I-UPF and if a SMF is unable to determine whether the UPF will be relocated, the SMF may not send N2 SM information (e.g., which may include an I-UPF tunnel information) in a N11 message to the AMF. The AMF may initiate a paging procedure to a WTRU. If the AMF receives a service request from the WTRU and the AMF has not received N2 SM information from the SMF, the AMF may provide the WTRU location to the SMF. The SMF may send N2 SM information (e.g., when the UPF relocates).

<FIG> illustrates an example UPF relocation during the network triggered service request procedure. The WTRU may have established a PDU session via old I-UPF and A-UPF, and the WTRU may be in idle state (e.g., at <NUM>).

An old I-UPF may receive a downlink (DL) data of the PDU session (e.g., at <NUM>). The old I-UPF may notify the SMF of DL data event (e.g., at <NUM>). The SMF may send a N11 message to indicate that DL data is received (e.g., at <NUM>). The SMF may not be able to determine if the WTRU is in the serving area of the UPF (e.g., since the SMF may not be aware of the current location of the WTRU). If the SMF is not able to determine whether the UPF will be relocated, the SMF may not include N2 SM information (e.g., in a N11 message).

The SMF may include a WTRU location request indication to request (e.g., request explicitly) the WTRU AMF to perform one or more procedures associated with the WTRU location (e.g., at <NUM>-<NUM>). The AMF may perform the paging procedure (e.g., in <NUM> and/or <NUM>). The WTRU may send a service request to the AMF (e.g., in <NUM> and/or <NUM>). The RAN may include the WTRU location to the message. The AMF may determine whether to request SM information (e.g., N2 SM information) from the SMF (e.g., at <NUM>-<NUM>) based on whether the SM information (e.g., N2 SM information) is received, for example in <NUM>. If the N2 SM information is not received, the AMF may proceed with sending a N11 message to the SMF (e.g., at <NUM>). If the N2 SM information is received, one or more of procedures/messaging from <NUM> to <NUM> may be skipped. The AMF may send a N11 message with the WTRU location to the SMF (e.g., at <NUM>). The SMF may determine whether the I-UPF is relocated according to the WTRU location and may update the N4 session with the A-UPF (e.g., at <NUM>-<NUM>). The data path may be established (e.g., at <NUM>-<NUM>).

<FIG> illustrates an example of UPF relocation during the network triggered service request procedure. For example, when downlink data notification is received from the I-UPF and if the SMF is unable to determine whether the UPF will be relocated, the SMF sends SM information (e.g., N2 SM information) to the AMF. The SM information (e.g., N2 SM information) indicates the area of validity for N2 information, and may include the available area (e.g., current I-UPF serving area or a set of tracking area/cell lists). The AMF may receive a service request from the WTRU (e.g., after the paging) and the AMF may determine whether the WTRU is located in the available area of N2 SM information (e.g., based on the WTRU location information determined from the service request). The AMF may determine whether to update the N2 SM information. The AMF may determine to request an updated N2 SM information. The AMF may determine to use N2 SM information received in <NUM> (e.g., in <NUM>) for the WTRU based on the WTRU location.

If the WTRU is not located within the available area of N2 SM information from the SMF (e.g., if the AMF determines that the WTRU is not located within the available area based on the N2 SM information), the AMF may send the WTRU location to the SMF and may request an updated N2 SM information from the SMF (e.g., via one or more of <NUM>-<NUM> from <FIG>).

If the WTRU is located in the available area of N2 SM information (e.g., if the AMF determines that the WTRU is located within the available area based on the N2 SM information (e.g., received in <NUM>)), the AMF may forward the N2 SM information (e.g., may send a N2 request (e.g., that may include N2 SM information in <NUM>)) to the RAN (e.g., <NUM> (e.g., skipping <NUM>-<NUM>)). The WTRU and the RAN may establish a radio resource control (RRC) connection (e.g., at <NUM>), and establish a tunnel from the A-UPF to the new I-UPF for data packets.

Comparing the procedure of <FIG>, many elements are similar. Comparing the procedure of <FIG>, <FIG> and <FIG> are different. For example, in <FIG> (e.g., at <NUM>), the SMF may include N2 SM information (e.g., old I-UPF tunnel information) and/or related available area (e.g., old I-UPF node serving area, a WTRU tracking area, or a RAN cell coverage area). For example, in <FIG> (e.g., at <NUM>), the AMF may determine whether the N2 SM information is available for the WTRU based on the WTRU location.

In an example, the AMF may receive the UPF service area information from the SMF at the time of the PDU session establishment. The AMF may store the UPF service area information with the corresponding PDU session ID. The AMF may use the saved UPF service area information during the service request procedure to determine if the WTRU is located in the UPF service area (e.g., as shown in <NUM> in <FIG>) to determine whether the N2 SM information received (e.g., in <NUM>) is available for the WTRU based on the WTRU location. If the WTRU is not located in the received UPF service area, the AMF may request a new SM information (e.g., N2 SM information) from the SMF (e.g., via one or more <NUM>-<NUM>).

<FIG> illustrates an example of UPF relocation during the network triggered service request procedure. For example, the SMF may receive a downlink data notification from the I-UPF (e.g., at <NUM>). The SMF may send the SM information (e.g., N2 SM information) to the AMF (e.g., via a N11 message; <NUM>). A WTRU may be paged (e.g., <NUM>-<NUM>). The AMF may receive a service request from the WTRU (e.g., <NUM>-<NUM>), and the AMF may forward the SM information (e.g., N2 SM information) to the RAN (e.g., <NUM>). The AMF may provide the WTRU location to the SMF (e.g., at <NUM>). The SMF may determine whether the I-UPF is relocated. If the SMF determines that the I-UPF is relocated, the SMF may notify the RAN about the updated N2 SM information.

As shown in <FIG>, the AMF may include WTRU location in the N11 message. When the SMF receives the WTRU location from the AMF (e.g., at <NUM>), the SMF may determine whether to perform I-UPF relocation (e.g., at <NUM>). If the SMF determines that I-UPF is not relocated, one or more of <NUM>-<NUM> may be skipped (e.g., as the new I-UPF may not need to be determined). If the SMF determines that I-UPF is relocated, the SMF may determine new I-UPF based on the WTRU location information (e.g., at <NUM>). The SMF may update the N4 session with the A-UPF (e.g., at <NUM>). When the SMF performs UPF selection (e.g., in at <NUM>), the SMF may include updated N2 SM information (e.g., if any, in <NUM>). For example, the updated N2 SM information may include the tunnel information of the new I-UPF. If the AMF receives a new N2 SM information (e.g., in <NUM>), the AMF may forward the new N2 SM information to the RAN to update the N2 SM information. The RAN node may reply back to the AMF. For example, the RAN node may reply back to the AMF with a N2 acknowledgement (ACK) message when the N2 SM tunnel information is received.

Signaling (e.g., extra signaling) in UPF relocation with SMF change when a WTRU is idle may be reduced. <FIG> illustrates an example N9 data path release procedure. For example, the SMF may trigger N9 data path release if the AMF determines that the N9 data path may not be maintained. For example, the WTRU may move out of the I-UPF serving area (e.g., the N9 data path maintenance may be skipped). A N9 release indication may be included in a N11 PDU session deactivation request. The N9 release indication may indicate that the I-SMF to release the N3 data path and/or to release the N9 data path. When the N9 data path is released, extra signaling in the UPF relocation with SMF change (e.g., when the WTRU is idle) may be skipped. The procedure described herein may be available when the AMF selects and/or communicates through an I-SMF (e.g., an architecture such as that described in <FIG>).

One or more of the following elements may be provided for N9 data path release procedure shown in <FIG>. A WTRU may establish a PDU session via one or more I-SMFs and/or A-SMFs (e.g., in <NUM> of <FIG>). The AMF may determine to release a N9 data path based on the WTRU location (e.g., in 2c). For example, the AMF may release the N9 data path based on the received indication in a registration procedure when the WTRU is idle. The AMF may release the N9 data path based on the WTRU state. The AMF may release the N9 data path when the N2 interface is released. The AMF may release the N9 data path based on one or more local policies.

The AMF may send a PDU session deactivation request (e.g., a N11 PDU session deactivation request) to the I-SMF (e.g., in <NUM>). The N11 PDU session deactivation request may include a release indication (e.g., a N9 release indication). The N11 PDU session deactivation request may include an AMF ID and may be forwarded to the A-SMF. The AMF ID may be used to communicate between A-SMF and AMF (e.g., directly) when the N9 data path is released. The I-SMF may send the N11 PDU deactivation request to the A-SMF (e.g., in <NUM>). The N11 PDU deactivation request may include the AMF ID. When the A-SMF receives the deactivation request message, the A-SMF may store the AMF ID for future communication with AMF (e.g., when N9 data path is released). The A-SMF may modify the N4 session with A-UPF to release N9 data path (e.g., in <NUM>). The A-SMF may send a response to the I-SMF (e.g., in <NUM>). For example, the A-SMF may send a PDU deactivation acknowledgement response to the I-SMF. The I-SMF may modify the N4 session with I-UPF to release one or more (e.g., all) WTRU context, including N9 data path (e.g., in <NUM>). The I-SMF may remove the WTRU context stored in the I-SMF.

The AMF may send a PDU session deactivation request (e.g., N11 PDU session deactivation request) to the A-SMF (e.g., directly), as shown in <NUM>' of <FIG>. The AMF ID may be included in order to be forwarded to the A-SMF. For example, the A-SMF may communicate with the AMF directly based on the AMF ID when the N9 data path is released. The A-SMF may modify the N4 session with the A-UPF to release N9 data path (e.g., in <NUM>'). The A-SMF may send a response to the AMF (e.g., in <NUM>'). For example, the A-SMF may send a N11 PDU acknowledgement response to the AMF. The AMF may send a N11 PDU session deactivation request to the I-SMF (e.g., in <NUM>'). The N11 PDU session deactivation request may include a N9 release indication. The I-SMF may modify the N4 session with I-UPF to release one or more (e.g., all) WTRU context, including N9 data path (e.g., in <NUM>'). The I-SMF may remove the WTRU context stored in the I-SMF.

<FIG> illustrates an example architecture with one or more SMFs. For example, the AMF may communicate with A-SMF and/or I-SMF. During a PDU session establishment, registration procedure, and/or AMF relocation procedure, an AMF ID may be provided to A-SMF and/or I-SMF. The A-SMF and/or I-SMF may be aware of the AMF ID (e.g., as shown in <FIG>). The architecture shown in <FIG> may allow A-SMF and/or I-SMF to interact with the AMF for a particular PDU session. The AMF ID may be passed on to A-SMF and/or I-SMF. One or more of the following procedures may be performed to communicate with the AMF ID to A-SMF and/or I-SMF.

<FIG> illustrates an example AMF ID provided to an A-SMF via an I-SMF. For example, the AMF ID may be provided to the I-SMF (e.g., first) and may be provided to the A-SMF. The WTRU may generate a PDU session establishment request (e.g., <NUM> of <FIG>). The PDU session establishment request may include a PDU session ID and/or service and session continuity (SSC) mode. The AMF may perform the SMF selection to select A-SMF and/or I-SMF (e.g., <NUM>). The AMF may send a PDU session establishment request to the I-SMF in a N11 message (e.g., <NUM>). The AMF may include the AMF ID in the message. The I-SMF may send a PDU session related SM information and/or the AMF ID to the A-SMF (e.g., <NUM>). The A-SMF may store the AMF ID for future communication with AMF directly. The A-SMF may establish a session (e.g., a N4 session) with the A-UPF (e.g., <NUM> of <FIG>). A PDU session establishment accept message may be sent back to the I-SMF (e.g., <NUM>). The I-SMF may establish a session (e.g., N4 session) with the I-UPF (e.g., <NUM>). A tunnel between the RAN and I-UPF may be established (e.g., <NUM>-<NUM>).

<FIG> illustrates an example AMF ID provided to the A-SMF via I-SMF. For example, the AMF ID may be provided to the A-SMF first and may be provided to the I-SMF. One or more elements shown in <FIG> may be the same as one or more elements shown in <FIG> (e.g., except AMF ID may be provided to the A-SMF first, and the AMF ID may be provided to the I-SMF.

Claim 1:
A session management function, SMF, node, the SMF node comprising:
a processor and a transmitter/receiver unit, the processor and the transmitter/receiver unit configured to, during a network triggered service request procedure:
send a N2 session management, SM, information to an access control and mobility management function, AMF, node, wherein the N2 SM information indicates an area of validity for N2 information;
receive from the AMF node a request for updated N2 SM information, wherein the request includes an indication of a wireless transmit receive unit, WTRU, location;
update the N2 SM information based on the indication of the WTRU location; and
send the updated N2 SM information to the AMF node.