Servers in the IoT communication path

Abstract

A radio network such as a public land mobile network (PLMN), a user equipment device (UE), a server such as an IoT server, and a core network entity may be adapted to facilitate the transfer of a connection of a wireless device. For example, a first PLMN may provide limited access to a UE to assist the UE in finding a second PLMN for a complete connection. The entities may be adapted to support PLMN transfers associated with non-coverage, such as, for example, transfers initiated by UEs, PLMNs, servers, and core network entities in response to changed usage, congestion, etc.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 669,669, filed on May 10, 2018, entitled “Server in Internet-of-Things Communication Path,” the contents of which are incorporated herein by reference in their entirety. Background Art

[0003] The present disclosure relates to public land mobile network (PLMN) selection and switching in machine-to-machine (M2M), Internet of Things (IoT), web-of-things (WoT) systems, etc., such as those discussed in 3GPP TS 23.501, System Architecture for the 5G System; Stage 2, v15.0.0; TS 23.502, Procedures for the 5G System; Stage 2, v15.0.0; TS 23.122, Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode, v15.2.0; RP-172021, Study on NR-based Access to Unlicensed Spectrum; and 3GPP TS 21.905 Vocabulary for 3GPP Specifications, V14.1.1. Summary of the invention

[0004] A radio network such as a Public Land Mobile Network (PLMN) may be adapted to facilitate the transfer of a connection of a wireless device. Additionally, the radio network may be adapted to support PLMN transfers associated with non-coverage.

[0005] For example, the first radio network may be adapted to receive a request from a user equipment (UE) or from a second radio network to initiate a transfer of one or more devices from one radio network to another radio network. In addition, the first radio network may send a request to initiate a transfer of one or more devices from one radio network or another radio network to the user equipment or the second network.

[0006] To assist in network selection, the radio network may support the device by providing limited access. For example, a device such as a user equipment may receive system information related to network support for limited access for network selection assistance from a first network. The device may then send a modified registration request to the first network. The device and the first network use signaling to establish a limited registration, for example, to allow access to the first network for the limited purpose of discovering and transferring to a second network.

[0007] The user equipment and a server such as an IoT server may also be adapted to facilitate the radio network transfer. For example, the user equipment may send a manual network selection request to the server over the first network, wherein the request contains a list of networks found by the UE. The server may then send a manual network response to the user equipment, the response from the IoT server containing an indication to connect to a second network, for example, wherein the second network is from a list of networks provisioned by the user equipment. The UE may then deregister from the first network and register with the second network.

[0008] The manual network selection request may, for example, include one or more of: a list of networks (PLMN / RAT combinations) that the user equipment has found; the received signal strength or other metric for each network; the cell identity of the strongest cell for each network; and the address of the IoT server to contact.

[0009] The manual network selection request or response may be sent, for example, via a modified Non-Access Stratum (NAS) control message, embedded in a Registration Request or Response message, or sent over an IP connection to the IoT server.

[0010] For example, the UE may register with a first network and signal support for non-coverage related PLMN transfer. The UE may then receive a request to perform a network search from the IoT server. The UE may perform the search and send a list of found networks to the IoT server. The UE may receive a PLMN update request to transfer to a second network, where the second network may be on the list of found networks. The UE may then deregister from the first network and register with the second network. The PLMN update request may, for example, include: an activation time when to deregister from the first network and register with the second network; and a time window in which the UE should deregister from the first network and register with the second network.

[0011] A core network entity such as a device implementing a network function may be adapted to facilitate PLMN transfer. For example, a core network entity may determine that one or more UEs served by an IoT server should be transferred to another network. The entity may then send a UE transfer request to the IoT server, requesting assistance in transferring the UE. The UE may receive a UE transfer response from the IoT server, which has a list of UEs to be transferred and the target networks of these UEs. The entity may then send a PLMNUpdate request to the UEs on the list.

[0012] This operation of the core network entity may be implemented in a variety of ways. For example, the determination is based on: UL load, DL load, buffer load or signaling load, or some combination thereof. The UE transfer request may include, for example: a list of UEs, the location of the UE, the UE network load, and the reason for the transfer request.

[0013] The IoT server can be adapted to facilitate PLMN transfers in a variety of ways. For example, the IoT server can request context information from the IoT application server, the UE, and the network. The IoT server can, for example, evaluate whether a PLMN transfer is warranted based on the received context information. The server can determine that the UE on the first network should be transferred to an alternative network. The server can then send a UE transfer proposal to the alternative network to determine whether the alternative network is willing to accept the UE's registration. If so, the server can send a UE transfer request to the UE via the first network. For example, the evaluation performed by the IoT server can be based on transferring the UE to the alternative network to minimize IoT server communications, or to exploit the multicast capabilities of the radio network.

[0014] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] A more detailed understanding can be obtained from the following description, which is given by way of example in conjunction with the accompanying drawings.

[0016] Figure 1 is a block diagram of an example collection of entities in cellular and packet networks.

[0017] Figure 2 is a block diagram of an example IoT cellular deployment.

[0018] Figure 3is a block diagram of an example set of entities involved in home routed roaming.

[0019] Figure 4 is a block diagram of an example set of entities involved in a local breakout roaming.

[0020] Figure 5 is a block diagram of an example congestion use case.

[0021] Figure 6 and 7 A calling flow of an example method for PLMN selection triggered by an M2M / IoT device is shown.

[0022] Figure 8-10 A calling flow of an example method for PLMN reselection triggered by the core network is shown.

[0023] Figure 11-14 A calling flow of an example method for PLMN reselection triggered by an M2M / IoT server is shown.

[0024] Fig.15 An example roaming alternative is shown.

[0025] Figure 16-18 A call flow illustrating an example method for PLMN reselection to a non-roaming-visited routing PLMN is shown.

[0026] Fig.19 An example graphical user interface is illustrated.

[0027] Fig. 20 An example communication system is illustrated.

[0028] Fig.21 , 22 and 23 are system diagrams of example RAN and core networks.

[0029] Fig.24 Another example communication system is illustrated;

[0030] Fig.25 is a block diagram of an example apparatus or device, such as a WTRU; and

[0031] Fig.26 is a block diagram of an exemplary computing system. DETAILED DESCRIPTION

[0032] In this document, the term "device registration" refers to the method by which a device creates a signaling connection with the core network of the PLMN. Device registration can be done via an ATTACH REQUEST in 4G networks and a REGISTRATION REQUEST in 5G networks. Device registration allows the UE to connect to a mobile network and receive services from that network. Device registration is sometimes referred to as "device association" or "device attachment".

[0033] In this article, the term "M2M / IoT application" refers to applications that remotely control / monitor / configure M2M / IoT devices. If these devices are cellular devices, this is usually done through the use of services provided by the M2M / IoT server and through the wireless cellular network. 3GPP usually refers to such applications as application servers (AS).

[0034] In this article, the term "M2M / IoT Server" refers to an infrastructure node that provides M2M services to M2M / IoT devices. These services reduce the burden on M2M / IoT applications and include services such as discovery, access control, and connectivity. For example, oneM2M IN-CSE is an M2M / IoT server that follows the oneM2M standard. 3GPP refers to this entity as a Service Capability Server (SCS) or Application Function (AF).

[0035] As used herein, the term "PLMN transfer" refers to a transfer involving the switching of a cellular device from one PLMN to another PLMN. A PLMN transfer may involve switching one or both of a radio access network and / or a core network.

[0036] Table 1

[0037] Abbreviations

[0038]

[0039]

[0040]

[0041] Cellular network entity (network function)

[0042] Figure 1 A plurality of cellular network entities and cellular network functions related to the systems, methods and apparatus described herein are shown. See 3GPP TS 21.905 Vocabulary for 3GPP Specifications, V 14.1.1.

[0043] refer to Figure 1, Mobility Management Entity (MME) is an entity within the cellular network that manages registration, mobility, and UE reachability in IDLE mode. MME is also involved in authentication and authorization.

[0044] The Access and Mobility Management Function (AMF) is a network function within a 5G cellular network that handles registration, connection, mobility, and reachability management. The AMF is also involved in security: access authentication, access authorization, and deriving keys specific to the access network. As such, the AMF is functionally similar to the MME.

[0045] The Home Subscriber Server (HSS) is an entity within the cellular network that stores subscription information for connecting devices. The subscription information includes the subscriber identity (in the form of an IMSI) and security keys for authentication, encryption, and data integrity. The HSS may also include other parameters associated with the subscription, including the services that can be accessed, the quality of the services they will receive, the access technologies they can use, charging models, etc. In the examples herein, it is generally assumed that the HSS includes the functionality of an Authentication Center (AuC). However, this AuC functionality may be located in a separate entity.

[0046] Unified Data Management (UDM) is a network function within the 5G cellular network that stores subscription information for connected devices. UDM functions similarly to HSS. In some cases, operator subscription information may be stored in a Unified Data Repository (UDR), in which case UDM will be a front-end form of retrieving subscription data from the UDR.

[0047] The Service Capability Exposure Function (SCEF) is an entity within the cellular network that exposes the services and capabilities provided by the 3GPP network interface. The SCEF allows third-party applications to determine UE reachability, set up monitoring of network events, allow group message delivery, etc.

[0048] The Network Exposure Function (NEF) is a network function that exposes the services and capabilities provided by the 3GPP network. For example, the NEF also provides a means for third-party applications to provide information to the cellular network, such as mobility or communication patterns. As such, the NEF is similar in functionality to the SCEF.

[0049] The Policy and Charging Rules Function (PCRF) is an entity within a cellular network that aggregates information to and from the network, operations support systems, and other sources (such as external third-party servers) in real time, supports the creation of rules, and can make policy decisions based on this input. The rules are provided to subscribers and other entities in the 3GPP network that manage traffic from these subscribers.

[0050] The Policy Control Function (PCF) is a network function that receives input from subscription information and third-party servers, supports a unified policy framework to manage network behavior, and provides policy rules to the control plane functions to enforce them.

[0051] A network data analysis function (NWDAF) is a network function that enables other network functions to request and obtain different types of network analysis information, such as load level information of a network slice instance, for example.

[0052] 5G-RAN is a New Radio (NR) radio access network, which is connected to, for example, a 5G core network.

[0053] 4G-RAN is RAN for LTE (Long Term Evolution).

[0054] IoT Cellular Deployment

[0055] Figure 2 Describes a typical IoT cellular deployment. M2M / IoT applications are applications that remotely control / monitor / configure M2M / IoT devices. If these devices are cellular, this is usually done with the help of services provided by an M2M / IoT server and over the wireless cellular network. 3GPP usually refers to such applications as Application Servers (AS). oneM2M usually refers to such devices as Infrastructure Application Entities (IN-AE).

[0056] An M2M / IoT server is a server that provides value-added M2M / IoT services to M2M / IoT applications and M2M / IoT devices. The main purpose of an M2M / IoT server is to reduce the burden on M2M / IoT applications and M2M / IoT devices. An M2M / IoT server provides many functions, such as data storage, data advertising, access control, etc. In most cases, it acts as a middleman between M2M / IoT applications and M2M / IoT devices. Therefore, applications cannot communicate directly with devices. Instead, devices store their data in the M2M / IoT server, which can later be retrieved from the 2M / IoT server by M2M / IoT applications. 3GPP typically refers to M2M / IoT servers as service capability servers. oneM2M typically refers to M2M / IoT servers as infrastructure capability service entities (IN-CSE).

[0057] from Figure 2It will be appreciated that an M2M / IoT server can serve many different M2M / IoT applications (e.g., APP1, APP2, APP3, and APP4). M2M / IoT devices can be associated / attached / registered to different networks, and therefore, an M2M / IoT server serving these devices will have an interface to each of these networks (e.g., Network 1 and Network 2). M2M / IoT applications can communicate with M2M / IoT devices that are associated, attached, or registered to different networks. M2M / IoT devices can communicate with many different M2M / IoT applications. An M2M / IoT server is a funnel point between M2M / IoT applications and networks and M2M / IoT devices.

[0058] PLMN Selection

[0059] In 3GPP, a device with cellular functionality is also referred to as a UE, and a network operator is also referred to as a Public Land Mobile Network (PLMN). A PLMN is usually contained within a country's borders. Typically, an operator will have one PLMN per country, but in some cases, an operator may have multiple PLMNs within a country's borders.

[0060] The UE needs to periodically perform a process known as PLMN selection to find and register with the network that will provide its cellular service to the UE. PLMN selection is defined in TS 23.122, Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode, v15.2.0. The process is based on a set of rules defined in the UE. The UE usually operates on its Home PLMN (HPLMN) or Equivalent Home PLMN (EHPLMN). However, for example, if the UE loses coverage or is roaming abroad, a Visited PLMN (VPLMN) can be selected. There are two PLMN selection modes in TS 23.122: automatic mode and manual mode.

[0061] Automatic mode utilizes a list of PLMN / access technology combinations in priority order. The highest priority PLMN / access technology combination available and allowable is selected.

[0062] In manual mode, the UE indicates to the user which PLMNs are available. Only when the user makes a manual selection will the UE attempt to obtain normal service on the PLMN.

[0063] The UE may maintain multiple lists in its USIM. In the EHPLMN list, the UE may store a set of PLMNs that are equivalent to the HPLMN. For example, an operator with more than one assigned Mobile Network Code (MNC) may use the EHPLMN list. In the user controlled PLMN selector with access technology list, the UE may store a list of PLMNs provided by the user. In the operator controlled PLMN selector with access technology list, the UE may store a list of PLMNs provided by the network.

[0064] The UE may store a forbidden PLMN list, e.g. a list of PLMNs that are forbidden by the network. For example, the UE may be added to such a list after a registration attempt to which the network responds with a "PLMN not allowed" message. A UE in automatic mode should not attempt to register with a PLMN on this list. If registration in manual mode is successful, or a timer associated with the PLMN entry expires, the PLMN is removed from the list.

[0065] Once the UE has registered on a PLMN, this PLMN is called the registered PLMN (RPLMN). To avoid ping-pong of the UE from one PLMN to another and to speed up the initial startup time, the UE will always try to re-register on the last or previous RPLMN.

[0066] At switch on or recovery from lack of coverage, if the RPLMN is no longer available and the UE is in automatic mode, then the UE will autonomously select the highest priority PLMN it found during the PLMN search. Conversely, if the RPLMN is no longer available and the UE is in manual mode, then it will display a ranked list of PLMNs it found during the PLMN search. The user is then expected to select from one of the found PLMNs.

[0067] The operation is slightly different when roaming in a visited PLMN. In this case, the UE periodically attempts to obtain service on its HPLMN (or an equivalent HPLMN or a higher priority PLMN / access technology combination listed in the "User Controlled PLMN Selector" or "Operator Controlled PLMN Selector").

[0068] Turn or roam

[0069] "Roaming Steering" can be used to steer the UE to a specific PLMN. If the UE receives a command of type "Roaming Steering", certain actions are expected to be taken. First, the UE shall replace the highest priority entry in the "Operator-controlled PLMN selectors with access technology" list stored in the UE with the list provided in the received command. Second, if present in the list in the received command and in the prohibited PLMN list, the UE shall delete the PLMN identified by the list in the received command from the prohibited PLMN list. Third, in subsequent attempts to access a higher priority PLMN, the UE shall take the new information into account. Finally, the UE shall immediately attempt to obtain service on the higher priority PLMN.

[0070] Inter-PLMN communication (for roaming)

[0071] 5G networks allow two modes of roaming: home routing, such as Figure 3 as shown in ; and local breakout, as Figure 4 The control plane communication between the home PLMN and the visited PLMN is through the Security Edge Protection Proxy (SEPP) and over the N32 interface. SEPP is a non-transparent proxy that mainly supports message filtering and policy management on the inter-PLMN control plane interface. The user plane communication is through the N9 interface, which carries multiple PDU sessions from the VPLMN to the HPLMN over a UDP / IP connection.

[0072] Shared and unlicensed spectrum

[0073] LTE devices can already use unlicensed and shared spectrum, and new research projects have been started in 5G to study 5G NR operating in unlicensed spectrum (both licensed auxiliary spectrum and standalone spectrum).

[0074] In Study Project RP-172021, Study on NR-based Access to Unlicensed Spectrum, objectives include: “Coexistence methods in unlicensed and LTE-based LAA and with other existing RATs within and between NR-based operations in accordance with regulatory requirements in bands such as 5 GHz, 37 GHz, 60 GHz”. In particular, the study project will use the coexistence methods already defined for the 5 GHz band in the context of LTE-based LAA as a baseline for 5 GHz operation. However, enhancements for 5 GHz over these methods are within scope. As a high-level goal, the impact of NR-based operation in unlicensed spectrum on deployed Wi-Fi services (such as data, video, and voice services) should not be greater than that of additional Wi-Fi networks on the same carrier.

[0075] NSSP and URSP

[0076] UE Routing Selection Policy (URSP) is a policy provided by the PCF in the 5GC to the UE. The UE uses these policies to determine how to route outgoing traffic. Traffic can be routed to an established PDU Session, it can be offloaded to a non-3GPP access outside of a PDU Session, or the establishment of a new PDU Session can be triggered.

[0077] URSP may include: SSCMSP (SSC mode selection policy) for mapping traffic to SSC mode; NSSP (network slice selection policy) for mapping traffic to S-NSSAI; DNN selection policy for mapping traffic to DN; and access network preference for mapping traffic to access network type. The UE may also have local preferences that can be used to determine how to treat traffic. Local preferences take precedence over URSP.

[0078] Congestion Use Case Example

[0079] Figure 5 is a block diagram of an example congestion use case. Figure 5 In the example, an M2M / IoT server interfaces with three operator networks (Operator 1, Operator 2, and Operator 3) through their corresponding Exposed Functions (EF). A fleet management company (TrackUS) has multiple sensors installed in all of its trucks. The vast majority of these devices generate very little data and are of low priority, however, a few of them are cameras that are turned on regularly for safety or surveillance reasons. TrackUS requires complete national coverage, so it negotiated preferential rates with two national operators (i.e., Operator 1 and Operator 3). Both rates are very good, but the rate from Operator 1 is slightly better. Therefore, TrackUS prefers to connect its devices / sensors to Operator 1.

[0080] Operator 1 is experiencing some severe congestion on its signaling channels in a particular cell due to traffic congestion. In a 4G network, the EPC could address this issue in a "brute force" manner and prohibit select devices from accessing the network. However, instead of blocking low priority sensor devices, Operator 1 decides to transfer some of these devices to another operator. Operator 1 requests the M2M / IoT server to assist in the transfer because the M2M / IoT server has valuable UE context information (e.g. preferred operator) and is in a better position to determine which sensors to transfer to another operator.

[0081] The M2M / IoT server finds that operators 2 and 3 provide the necessary services. Operator 3 is the preferred operator and is willing to accept these devices. The M2M / IoT server notifies the low priority sensor device to connect to this operator. The sensor disconnects from operator 1 and reconnects to operator 3 to obtain service.

[0082] Example Problems Prompted by Common Solutions

[0083] Existing standards provide for two situations in which UEs can be transferred between PLMNs. The first situation is during international roaming, for example, when the HPLMN does not provide service. In this case, the UE registers with the VPLMN, and the HPLMN does not provide service in the country where the UE is roaming. In IDLE mode, the UE will periodically attempt to register with a higher priority PLMN;

[0084] The second scenario is during national roaming, in case there are coverage holes in the coverage of an operator. The HPLMN and VPLMN are located at the same country border, but the UE can be located at a location where the reception from the HPLMN is very poor or non-existent. This is called extended coverage or extended national roaming in Canada, for example. The UEs from operator 1 can be pushed to a competitor's network (operator 2) if operator 1 does not provide coverage to those UEs. The subscriber does not have to pay additional roaming charges, and the subscriber is entitled to almost the same set of services in the competitor's network.

[0085] In most cases, PLMNs manage their own networks and they share UEs with each other only for coverage reasons (or due to poor signal quality in the case of national roaming or non-existent in the case of international roaming). There is no conventional mechanism to share UEs between PLMNs for non-coverage reasons (e.g., to resolve congestion or for some other optimization). As a result, the PLMN may be required to stop providing service to some UEs, for example by disconnecting these UEs or rejecting registration requests. Furthermore, even if such transfers between PLMNs are allowed, the PLMN may not be in the best position to select which UEs to transfer. The unique position of the SCS in the IoT communication path is not fully utilized.

[0086] The SCS has or is able to obtain knowledge of network context and visibility across multiple PLMNs (one PLMN may not necessarily know information about neighboring PLMNs), including: slice information (number of slices, type of slices); load on the network or network slice (user plane and control plane); coverage area (or coverage hole) of the network; number of UEs; number of active (CONNECTED, IDLE or SUSPEND) UEs in the network or network slice; and average UE latency (for mobile-originated or mobile-terminated traffic).

[0087] SCS has or is able to obtain: a large amount of UE context information, such as: any information subscribed by the UE; the number of flows for each UE; the location of the UE; the mobility pattern of the UE; the reachability of the UE; the historical flows to / from the UE; the power saving state of the UE; and the transmission characteristics (communication mode) to / from the UE.

[0088] For the purpose of illustration, a solution is presented herein as a means of sharing UEs between PLMNs for non-coverage reasons (e.g., to resolve congestion or for some other optimization). However, the same solution can also be used to share UEs between PLMNs for coverage reasons. For example, a UE can be transferred to a mobile virtual network operator (MVNO) using any of the techniques described herein.

[0089] PLMN Transfer

[0090] Figure 6-14 The calling flow of FIG. 1 shows an example method for implementing PLMN transfer. Figure 6-14 In the example, it is assumed that the UE is initially connected to its home PLMN and is transferred to a VPLMN. It should be understood that the solution can also be applied to the case where the UE is connected to a visited PLMN and the UE is transferred to another VPLMN or HPLMN. For example, the UE is connected to VPLMN1 and VPLMN1 becomes congested. In this case, VPLMN1 can request the server to transfer some UEs. The server can then determine that it can transfer the UEs to another VPLMN (VPLMN2) or bring them back to the HPLMN.

[0091] exist Figure 6-14 In each of the methods, whenever a new PLMN selection policy is provided to the UE, a new NSSP for the URSP rule may also be provided.

[0092] PLMN reselection triggered by M2M / IoT devices

[0093] The device owner can implement manual network selection through the M2M / IoT server. The M2M / IoT device provides a list of PLMN / RAT combinations to the M2M / IoT server, which then selects that combination to try.

[0094] It is assumed that some PLMNs will allow M2M / IoT devices to connect with very limited and restricted access, such as connecting via a restricted local operator service (RLOS). This access allows these devices to contact their M2M / IoT server and have the server assist in PLMN selection. These PLMNs may broadcast an indication that they support "restricted access for network selection assistance", or they may broadcast that they support RLOS, and the UE may use the RLOS connection to determine that the network supports "restricted access for network selection assistance" and then start "restricted access for network selection assistance" using the RLOS connection. Details are in Figure 6 and 7 and described below.

[0095] exist Figure 6 and 7 In the example of , it is assumed that an M2M / IoT device Dev1 is deployed, and the M2M / IoT application has notified the M2M / IoT server that the specific M2M / IoT device (Dev1) has a preferred PLMN / RAT list. For example, the list may include the following combinations from 3 PLMNs and 2 RAT types: PLMN1 / RAT1; PLMN1 / RAT2; PLMN2 / RAT1; PLMN3 / RAT1; and PLMN2 / RAT1.

[0096] In step 0, the PLMN of the core network 1 broadcasts that it supports "restricted access for network selection assistance" as part of its system information.

[0097] In step 1, DEV1 performs a PLMN search (as a result of power-up, loss of connectivity, or periodic search) and determines a list of candidate PLMN / RATs. For each entry in this list, DEV1 also determines the strength of the strongest cell (e.g., relative signal strength (RSS)). DEV1 does not see previously registered PLMNs in this list. It has no policy for which PLMN to select, or if such a policy exists, it is disabled. For example, the 3GPP UE can be set to manual network selection mode.

[0098] As part of the search, DEV1 may determine whether the PLMN allows "restricted access for network selection assistance".

[0099] In step 2, DEV1 registers with the core network. DEV1 may select from the found PLMN / RAT combinations that support "restricted access for network selection assistance". For example, DEV1 may randomly select from one of the found PLMN / RAT combinations, it may select the combination with the strongest signal, it may select the previously used PLMN / RAT combination, or it may select the first found PLMN / RAT combination. Figure 6 and 7 For purposes of example, assume the M2M / IoT device selects Core Network 1. The Registration Request may include Registration Type=Restricted Access for Network Selection Assistance, e.g., as an indication to the core network that this Registration Request is for limited access to allow the device to contact an M2M / IoT server.

[0100] In step 3, the core network 1 accepts the registration.

[0101] In step 4, DEV1 issues a new NAS control message ManualNetworkSelection request to the core network 1. For example, this message can be directed to the AMF of the core network 1. The request can include a PLMN / RAT list, such as a list of discovered cells. Each entry in the list can include the received signal strength of the strongest cell and the identity of the strongest cell (e.g., cell ID). Alternatively, the list can be sorted from the strongest to the weakest PLMN / RAT combination. The request can also include the address of the device's M2M / IoT server.

[0102] In step 5, the AMF of the core network 1 forwards the request to the NEF, which in turn forwards the request to the M2M / IoT server. The core network may include other UE context information in the request, such as the location of DEV1 (e.g., cell identity or tracking area identity) or the network slice being used.

[0103] Figure 6 The calling process is Figure 7 Continue in Figure 7 In step 6, the M2M / IoT server uses the stored preferred PLMN / RAT list and other received UE context information received in the request to select a PLMN / RAT combination. The server may have local policies to assist in selecting a PLMN / RAT combination. The server may display the received information on a graphical user interface to allow the user to select a PLMN / RAT combination. The server may send a notification to a configured third-party application server to enable it to select a PLMN / RAT combination.

[0104] Once the PLMN / RAT selection is made, the M2M / IoT Server sends a ManualNetworkSelection response back to the NEF of the Core Network 1, which sends it to the AMF and on to the M2M / IoT device.

[0105] In step 7 , the M2M / IoT device deregisters from the core network 1 and registers with the core network 2 .

[0106] As Figure 6 As an alternative to step 4, the UE can establish a PDU session in the core network and send a ManualNetworkSelection request to the M2M / IoT server using IP. For example, an RLOS connection can be used to reach the IoT server.

[0107] As Figure 6 As another alternative to step 4 of , the message can be forwarded from the AMF to the PCF. The PCF can generate a new preferred PLMN / RAT list and send it to the UE. The PCF can involve the IoT server in this process by querying the IoT server (via the NEF) to obtain its PLMN preference.

[0108] As another alternative, you can send along with your initial registration request Figure 6 The UE may then extract the PLMN information from the ManualPLMNSelection response and attempt a subsequent registration with this PLMN.

[0109] PLMN reselection triggered by the core network

[0110] When the core network detects a situation that can be resolved by transferring some UEs to another PLMN, the core network may seek assistance from the M2M / IoT server.

[0111] It is assumed that the M2M / IoT server has a preference for a PLMN and wishes to control aspects of transferring a device to another PLMN. Details such as Figure 8-10 shown and described below.

[0112] exist Figure 8In step 1 of FIG. 1 , an M2M / IoT device (DEV1) registers with the core network 1. As part of the registration, the UE includes its capabilities, where DEV1 indicates that it is capable of core network directed PLMN reselection. Alternatively, this information may be part of the device subscription information. The registration accept message may indicate to the UE whether the network supports this capability, or the indication may have been broadcast by the network.

[0113] In step 2, the core network 1 determines to start monitoring the problem condition. AMF1 issues a MonitorSubscribe request to NWDAF1 associated with the core network 1. NWDAF provides high-level analytical data about the core network 1. For example, AMF1 can subscribe to monitor: user plane UL and / or DL ​​load in RAN; user plane UL and / or DL ​​load in the core network; control plane UL and / or DL ​​load in RAN; control plane UL and / or DL ​​load in the core network; or buffer load in the core network (e.g., for unreachable UEs).

[0114] Furthermore, the granularity of subscription requests can be for a specific cell, tracking area, network slice, UE, or group of UEs. Requests can be for periodic updates, or based on a monitored criterion exceeding a threshold.

[0115] For the call flow, it is assumed that a request has been made to notify AMF1 when the buffering, device count, control plane connection or user plane connection load in the core network exceeds a threshold (e.g., 70% of maximum capacity).

[0116] In step 3, at some point in time, the buffer load exceeds the threshold. NWDAF1 sends a MonitorNotify request to the AMF. This may include a list of UEs that caused the buffer overflow.

[0117] In step 4, AMF1 determines that most of the UEs causing problems are using the services of the M2M / IoT server. AMF1 may decide to initiate the process of offloading multiple UEs to another PLMN. Alternatively, AMF and / or NWDAF may provide the necessary information to PCF (UEs causing problems, M2M / IoT servers serving these UEs, load on the network, location of UEs causing problems, etc.), and PCF may use a local policy to determine whether the network should initiate offloading of some UEs to another PLMN.

[0118] Figure 8 The calling process is Fig. 9 Continue in Fig. 9In step 5, AMF1 sends a UETransferInd request to the M2M / IoT server. The request may contain UE context information, including a list of UEs for potential transfer, or a request to transfer a certain percentage of UEs. This request is sent to the M2M / IoT server via NEF1. This request may include indications of the location of the UE, observed traffic load (user plane and control plane), reachability period of the UE, network slice type of the UE, etc. This request may also include an indication of the reason for the transfer (e.g., S-GW DL buffer load, UL signaling load, etc.). This request may be sent to the PCF instead of the M2M / IoT server. The PCF can then decide which devices should be offloaded.

[0119] In step 6, the M2M / IoT server (or PCF1) determines the UE to which it should transfer. The call flow assumes that DEV1 is one of these UEs. The M2M / IoT server determines the offload PLMN for DEV1. For example, it may know that Core Network 2 is the preferred PLMN for this UE, or it may make a decision based on the UE context information in the request. For example, the M2M / IoT server may have a coverage map of all PLMNs and may determine which PLMNs provide service at the UE's current location and are suitable candidates for offloading PLMNs. PCF1 may obtain this information from the M2M / IoT server if necessary.

[0120] In step 7, the M2M / IoT Server (or PCF1) asks the Core Network 2 whether it is willing to accept DEV1 (using a UETransfer request). As part of this request, the M2M / IoT Server (or PCF1) may include any UE context it has available (communication mode, observed traffic load, reachability period, location of the UE, etc.). The message is sent to AMF2 (or to PCF2) via NEF2. PCF1 may communicate with the Core Network 2, if necessary, either directly, via SEPP, via NEF, or via the M2M / IoT Server.

[0121] In step 8, AMF2 (or PCF2) determines whether it is willing to accept the registration of DEV1. If so, a UETransfer response can be sent back to the M2M / IoT server. This may include an indication of a time window to perform this registration. The time window can be used to disperse registration requests from UEs transferred to core network 2. If the time window expires, core network 2 can assume that the UE will not be transferred to core network 2.

[0122] Core Network 2 may decide that it does not want to accept the registration of DEV1. This may be due to its own load issues, or because it has no or little coverage at the location of the UE.

[0123] exist Fig.10 In step 9, the M2M / IoT server (or PCF2) responds to the core network 1 with an indication of the UEs to be transferred and the new PLMN for these UEs. This information is included in the UETransferInd response message.

[0124] Fig. 9 The calling process is Fig.10 Continue in Fig.10 In step 10, AMF1 sends a PLMNUpdate request and the new PLMN information to DEV1. This can be done through a regular registration procedure, a tracking area update procedure, or through a new dedicated control plane procedure. Alternatively, AMF1 can send an SMS to DEV1 with a USAT REFRESH command qualifier of type "roaming redirection", effectively redirecting DEV1 to the selected PLMN (core network 2).

[0125] The request may also include an activation time to inform the UE when it should attempt to register on the core network 2. If a large number of UEs are transferred to the core network 2, this can be used to reduce the signaling load on the core network 2, as the activation time can be used to spread the registration requests to the core network 2.

[0126] In step 11, DEV1 deregisters from core network 1 and registers with core network 2 at an appropriate time.

[0127] As an alternative to steps 10 and 11, the PLMNUpdate request may include a time window over which an initial registration may be performed on the core network 2. DEV1 may then randomly select a time within this window to attempt its initial registration.

[0128] To assist the M2M / IoT server and provide additional UE context information, AMF1 may request the UE to report neighbor PLMN information in step 4. The UE may then perform a PLMN search and provide the found PLMN / RAT combination and an indication of the received signal strength of the PLMN / RAT combination to the core network 1. Alternatively, the UE may be configured to periodically measure the signal strength of neighboring PLMNs and report the signal information to the core network 1. This neighbor PLMN information may be included as part of the UE context information provided to the M2M / IoT server in step 5.

[0129] PLMN reselection triggered by M2M / IoT server

[0130] The M2M / IoT server may gather information and detect situations that may be beneficially resolved by transferring some UEs from one PLMN to another.

[0131] Due to its position in the communication path between the core network and the M2M / IoT applications, the M2M / IoT server is in a unique position to collect context information from both and determine the optimal PLMN to serve the device. Figure 11-14 and described below.

[0132] Fig.11 Step 1 and Figure 8 Same as step 1.

[0133] In step 2a / 2b, the M2M / IoT server collects context information from the core network. For example, this may include load information such as per cell, tracking area, network slice, UE, and UE group. The information may include network capacity information such as historical network usage over different time periods (e.g., hourly, daily, weekly, per holiday, etc.). Similarly, the information may include UEs that are part of a multicast group and UEs that use unlicensed or shared spectrum, as well as the type of spectrum.

[0134] The M2M / IoT server can subscribe to provide this information periodically and / or when it changes. The subscription can be configured on NWDAF, PCF, AMF or UDM / UDR via NEF.

[0135] In steps 3a and 3b, the M2M / IoT server collects information from the M2M / IoT applications. For example, the server may collect overall requirements from each M2M / IoT application, for example in the form of communication modes for different time periods.

[0136] In step 4, the M2M / IoT server uses the context information and the network status information to determine whether certain devices may need to be transferred from one PLMN to another PLMN. For example, the M2M / IoT server may determine to transfer UEs for the purpose of load balancing, sharing multicast groups, minimizing interference on shared spectrum, or optimizing resource and service allocation.

[0137] For example, for load balancing, the M2M / IoT server can aggregate the demand of all M2M / IoT applications and determine the overall demand of each UE. It also knows the available capacity of each core network. The M2M / IoT server can dynamically match the demand with the available capacity to spread the load of these UEs across all core networks. For example, it can determine that DEV1 should be on core network 1 between 8AM and 3PM, otherwise it should be on core network 2.

[0138] To share a multicast group, the M2M / IoT server may know that it has a multicast message to send to a group of UEs. A portion of this group of UEs is registered with core network 1 (subgroup 1), while the rest of the group of UEs is registered with core network 2 (subgroup 2). Instead of using a separate multicast group in each core network, the M2M / IoT server wants to create a multicast group in only one network. Therefore, it transfers all UEs from one subgroup to another core network. For example, the M2M / IoT server may determine that it needs to send multicast messages to DEV1 and 20 other devices on a regular basis. These 20 other devices are registered with core network 2 and are part of that network or multicast group. To take advantage of this existing group and avoid sending multicast messages to 2 different core networks, the M2M / IoT server may request DEV1 to register with core network 2.

[0139] To minimize interference on the shared spectrum, the M2M / IoT server can determine that it is communicating with two sets of UEs using the same shared spectrum. Set 1 UEs are registered to core network 1, while Set 2 UEs are registered to core network 2. The M2M / IoT server can also know that these devices are adjacent to each other. Since each of the two networks manages its shared spectrum separately, the UEs registered in the two networks compete with each other. Moving these two sets of UEs to a single core network allows the core network to better coordinate the traffic to and from these UEs and minimize interference.

[0140] To optimize resource and service allocation, the M2M / IoT server may determine that one or more UEs do not require full network services for a specific duration. In this case, the M2M / IoT server may purposefully and for a specific duration request a transfer of these UEs to a PLMN that supports "Restricted Access for Network Selection Assistance". This is followed by a PLMN reselection to a PLMN where the UE can receive full network services.

[0141] Fig.11 The calling process is Fig.12 Continue.

[0142] exist Fig.12In step 5 of , once the M2M / IoT server determines that it would prefer to transfer DEV1 from Core Network 1 to Core Network 2, it may need to retrieve other UE context information for Dev1. For example, it may need to verify that DEV1 is capable of PLMN transfer.

[0143] Fig.12 , 13 and steps 6-10 of 14 with Fig. 9 and 10 Steps 7-11 are similar.

[0144] Active PLMN Selection List

[0145] The M2M / IoT server can also determine a set of PLMN lists and supply this set to the UE. The UE can then use local policies to determine which PLMN list to use. The policy can be based on one or more of the following: UE location, UE load, applications running on the UE, etc.

[0146] The M2M / IoT server can collect information from the PLMN (coverage map, load, etc.) and the application server (served UE, UE trajectory, etc.) and determine one or more PLMN selection lists from this. These selection lists can then be transmitted to the UE via NAS signaling or via a certain USAT command to the USIM in the UE. The UE can then periodically use its local policy to select among the PLMN selection lists and perform PLMN selection / reselection.

[0147] For example, based on information collected from the core network and application servers, the M2M / IoT server can generate multiple PLMN selection lists based on the UE's current location and currently active applications. For example, the server can create the following five lists:

[0148] PLMN List 1: Location: City A, UE Application: Any

[0149] PLMN List 2: Location: City B, UE Application: Any

[0150] PLMN List 3: Location: Other Locations, UE Application: Application 1

[0151] PLMN List 4: Location: Other Locations, UE Application: Application 2

[0152] PLMN List 5: Default

[0153] The M2M / IoT server may then send these lists to the UE, for example via a USAT command or via the core network with which the UE is currently registered.

[0154] The UE updates its list and uses its local policy to determine which list to use. If no valid matching list is found, the UE may use the default PLMN list 5.

[0155] Non-roaming – visited route

[0156] M2M / IoT devices with limited radio access capabilities may not be able to be transferred to another PLMN. In such cases, an alternative roaming scheme called "Non-Roaming – Visited Routing" can be used.

[0157] exist Figure 6-14 In the discussion of , it has been assumed that the M2M / IoT device is either registered to its home PLMN or transferred to another PLMN (e.g., a visited PLMN). As far as the network is concerned, when the UE transfers from its home PLMN to a visited PLMN, it is actually roaming. 3GPP defines two variants of roaming: local breakout and home routing. Both variants refer to the user plane path. In the local breakout case, the user plane path stays in the visited PLMN and the VPLMN routes the data to the data network. In the home routing case, the user plane path returns to the home PLMN and the HPLMN routes the data to the data network. Fig.15 Configurations a, b, and c in Figure 3 illustrate the three alternatives - non-roaming, local breakout roaming, and home-routed roaming, respectively.

[0158] Fig.15 A total of six functional entities with five configurations are shown. The first entity is the UE, which is a device that requires services from a wireless operator. The UE is connected to the RAN entity based on its radio access capabilities. The second entity is the RAN_h, which is the radio access network functional entity of the home PLMN. The RAN_h corresponds to a specific technology and frequency band.

[0159] The third entity is RAN_v, which is the radio access network function entity of the visited PLMN. RAN_v corresponds to a specific technology and frequency band. The fourth entity is CN_h, ​​which is the core network function entity of the home PLMN. It corresponds to a specific type (e.g., EPC, 5GS) and specific capabilities (e.g., support for slicing, support for services).

[0160] The fifth entity is CN_v, which is the core network function entity of the visited PLMN. It corresponds to a specific type (e.g., EPC, 5GS) and specific capabilities (e.g., support for slicing and support for services). The sixth entity is DN, which is the data network with which the UE wishes to communicate.

[0161] To keep it simple, Fig.15 The internal network functions of the core network are omitted.

[0162] A fourth roaming alternative is possible for M2M / IoT devices. In some cases, M2M / IoT devices will only support a single RAT, and only the frequency bands of their preferred operator. These devices will only be able to connect to the RAN of the HPLMN.

[0163] Similarly, in some cases, an operator may not want to instantiate a dedicated network slice for just a few M2M / IoT devices. Rather, it may want to leverage its relationship with another operator that offers dedicated network slices. It may want to push these devices to that other operator.

[0164] However, due to their RAT limitations, these M2M / IoT devices will not be able to connect to the RAN of this other operator as the devices do not support the RAN and / or the frequency band. For such devices, another roaming alternative is proposed, called non-roaming visited routing (in Fig.15 In this alternative, the UE connects to RAN_h (the RAN of the home PLMN). The control plane and user plane traffic is then routed to the visited PLMN (CN_v), which provides the high-level services required by the UE. This avoids the home PLMN from providing these services.

[0165] Note that the functionality within CN_h may be variable. For example, it may have only minimal functionality to support inter-PLMN communications. It may provide a portion of the control plane functionality, or it may provide full user plane functionality. Similarly, it may provide access to data networks through its NEF, for example, using the UPF in CN_v to send / receive user plane traffic to / from the NEF of CN_h.

[0166] Since the latter two cases above rely on the HPLMN to route traffic to the DN, they are classified as "Non-Roaming – Partially Visited Routing" to distinguish them from the other cases. Fig.15 An alternative is shown in e).

[0167] This roaming alternative can be used in conjunction with Figure 6-14 To support such transfers, it is recommended that the entity triggering the transfer can specify the type of transfer it is requesting (roaming-local breakout, roaming-home routing, non-roaming-visited routing). For core network triggered PLMN reselection, the details are in Figure 16-18 Note that for readability and simplicity, Figure 6-18 The calling process is divided into several pages of the attached drawings. In addition, the entities involved in the calling process can be omitted on each page of the attached drawings to avoid confusion.

[0168] Fig.16 and 17 Steps 1-6 are the same as Figure 8 and 9 Steps 1-6 are similar.

[0169] exist Fig.17 In step 7 of , for example, once the M2M / IoT server has determined the UE to be transferred, other UE information (such as UE radio access capabilities) may be required from the core network 1.

[0170] Fig.16 and 17 The calling process is Fig.18 Continue in Fig.18 In step 8, the M2M / IoT server asks the core network 2 whether it is willing to accept DEV1 (e.g., using a UETransfer request). As part of this request, the M2M / IoT server may include any UE context available to it (communication mode, observed traffic load, reachability period, UE radio point access capabilities, type of transfer (roaming-local breakout, roaming-home routing, non-roaming-visit routing), etc.). This message is sent to AMF2 (or PCF2) via NEF2.

[0171] In step 9, AMF2 (or PCF2) decides whether it is willing to accept the registration of DEV1. If so, it sends a UETransfer response back to the M2M / IoT server. This may include an indication of the time window in which to perform this registration. It may also indicate that the UE can only be served using non-roaming-visited routing.

[0172] In step 10, the M2M / IoT server responds to the core network 1 with an indication of the UEs to be transferred, the new PLMN for these UEs and an indication of the roaming alternatives for these UEs. This information is included in a UETransferInd response message.

[0173] In step 11, if DEV1 has chosen to use the non-roaming - visited routing alternative, then AMF1 will set up inter-PLMN communications between the two PLMNs, for example as can be done for a roaming alternative.

[0174] The UE is not aware of this PLMN change and it continues to use the same RAN. Once the RAN nodes forward the user plane and control plane traffic to the Core Network 1, it is the responsibility of the Core Network 1 to route this traffic to the Core Network 2

[0175] As an alternative, for example in a shared network configuration, RAN_h may have connectivity with both CN_h and CN_v. The RANs in the HPLMN may broadcast that they are shared cells, for example shared between CN_h and CN_v. Based on the broadcast information, the UE may learn about the core networks available through the cell and the capabilities of each of these cells, for example in terms of supported network slices. In this alternative, Fig.18 Step 11 of will be replaced by the AMF change procedure, in which the AMF serving the UE is changed from AMF1 to AMF2.

[0176] Graphical User Interface

[0177] Fig.19 An example deployment with three graphical user interfaces (GUIs) is shown. For example, the (GUIs) may be implemented within the core network, at an M2M / IoT server, or at an M2M / IoT device. The interfaces may be used to trigger certain actions described in this document and to view status related to PLMN transfer operations.

[0178] For example, the GUI may be used at the UE to view the type of access of the UE (eg, restricted access for network selection assistance, RLOS, normal), or to trigger server-assisted network selection.

[0179] For example, the GUI can be used in the core network to configure or view the PLMN selection policy for non-coverage related PLMN transfer. For example, if the buffer load in the core network exceeds 70% of the maximum value and the number of registered UEs exceeds 1000, then configure the policy to transfer the UE.

[0180] For example, a GUI may be used in an M2M / IoT server to trigger a PLMN transfer for a UE or a group of UEs. This may include a target PLMN for each UE. A GUI may be used in an M2M / IoT server to input a preferred operator for a UE or a group of UEs.

[0181] Example Architecture

[0182] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also referred to as "5G". The development of the 3GPP NR standards is expected to continue and include the definition of next generation radio access technologies (new RATs), which are expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backwards compatible radio access in new spectrum below 7 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with sub-7 GHz flexible radio access, with cmWave- and mmWave-specific design optimizations.

[0183] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and any communications in vehicle communications with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive electronic calls (ecalls), disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robots, and aerial drones, among others. All of these use cases and others are contemplated herein.

[0184] Fig. 20An example communication system 100 is illustrated in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be generally or collectively referred to as WTRUs 102 or WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0185] It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Fig. 20 In the example of FIG. 1 , each of the WTRUs 102 is Figure 20-24 . It should be understood that for various use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, bus or truck, a train or airplane, etc.).

[0186] The communication system 100 may also include a base station 114a and a base station 114b. Fig. 20In the example of FIG. 1 , each base station 114 a and 114 b is depicted as a single element. In practice, the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements. The base station 114 a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 a, 102 b, and 102 c to facilitate access to one or more communication networks (e.g., the core network 106 / 107 / 109, the Internet 110, network services 113, and / or other networks 112). Similarly, the base station 114b may be any type of device configured to interface wiredly and / or wirelessly with at least one of the remote radio heads (RRHs) 118a, 118b, the transmission and reception points (TRPs) 119a, 119b, and / or the roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0187] The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, next generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0188] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a BSC, a RNC, a relay node, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may include three transceivers, eg, one for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and may therefore use multiple transceivers for each sector of the cell, for example.

[0189] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0190] The base station 114b may communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

[0191] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0192] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as a sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0193] The communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117 and / or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0194] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g or the RRHs 118a and 118b, TRPs 119a and 119b and / or RSUs 120a and 120b and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish an air interface 115 / 116 / 117 or 115c / 116c / 117c using, for example, Long Term Evolution (LTE) and / or Advanced LTE (LTE-A), respectively. The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0195] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g or the RRHs 118a and 118b, the TRPs 119a and 119b and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN) etc.

[0196] For example, Fig. 20The base station 114c in the figure can be a wireless router, a Home Node B, a Home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business place, a home, a vehicle, a train, an aerial, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., WRTU 102e) can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. As Fig. 20 As shown in FIG, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0197] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions (such as user authentication).

[0198] Although not in Fig. 20 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM or NR radio technology.

[0199] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, or a different RAT.

[0200] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 20 The WTRU 102g shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0201] Although not in Fig. 20 106 / 107 / 109. It will be appreciated that many of the concepts contained herein are equally applicable to a UE that is a WTRU and a UE that uses a wired connection to connect to a network. For example, concepts applicable to wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to a wired connection.

[0202] Fig.21 1 is a system diagram of an example RAN 103 and a core network 106. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig.21As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

[0203] like Fig.21 As shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b and 140c can communicate with corresponding RNC 142a and 142b via Iub interface. RNC 142a and 142b can communicate with each other via Iur interface. Each of RNC 142a and 142b can be configured to control the corresponding Node-B 140a, 140b and 140c to which it is connected. In addition, each of RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0204] Fig.21 The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0205] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.

[0206] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices.

[0207] The core network 106 may also be connected to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0208] Fig. 22 1 is a system diagram of an example RAN 104 and a core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0209] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0210] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig. 22 As shown in FIG. , eNode-Bs 160a , 160b , and 160c may communicate with each other via an X2 interface.

[0211] Fig. 22 The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0212] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0213] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring a user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.

[0214] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0215] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0216] Fig.231 is a system diagram of an example RAN 105 and a core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

[0217] The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the gNode-Bs, which may be a core network 109 via one or more gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, for example, the gNode-B 180a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a. It will be appreciated that the RAN 105 may employ other types of base stations, such as an eNode-B. It will also be appreciated that the RAN 105 may employ more than one type of base station. For example, RAN may employ eNode-B and gNode-B.

[0218] The N3IWF 199 may include a non-3GPP access point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using the 802.11 protocol.

[0219] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, etc. Fig.23 As shown in FIG. 1 , for example, gNode-Bs 180a and 180b may communicate with each other via an Xn interface.

[0220] Fig.23The core network 109 shown in the figure can be a 5G core network (5GC). The core network 109 can provide a variety of communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functions of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such a core network entity can be a device or computer system (such as a 5G core network) stored in a device or computer system configured for wireless and / or network communications. Fig.26 A logical entity implemented in the form of computer-executable instructions (software) stored in a memory of the system 90 shown in FIG. 1 and executed on a processor thereof.

[0221] exist Fig.23 In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network exposure function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It will also be appreciated that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Fig.23 The network functions are shown connected directly to each other, however, it should be appreciated that they may communicate via a routing agent such as a diameter routing agent or a message bus.

[0222] exist Fig.23 In the example of , the connectivity between network functions is realized via a set of interfaces or reference points. It will be appreciated that a network function can be modeled, described or realized as a set of services invoked or called by other network functions or services. The invocation of network function services can be realized via direct connections between network functions, message exchanges on a message bus, calling software functions, etc.

[0223] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not used in Fig.23 Shown in.

[0224] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0225] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that exchanges data packets. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to the packet data network by connecting the packet data network with the N6 interface or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0226] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via a 3GPP undefined radio interface technology. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0227] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N17 and N5 interfaces are not Fig.23 1. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to enforce these rules. The PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0228] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may be connected to network functions so that the network functions may add data to, read data from, and modify data in the repository. For example, the UDR 178 may be connected to the PCF 184 via an N36 interface. Similarly, the UDR 178 may be connected to the NEF 196 via an N37 interface, and the UDR 178 may be connected to the UDM 197 via an N35 interface.

[0229] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access the UDR 178. For example, the UDM 197 may be connected to the AMF 172 via the N8 interface, and the UDM 197 may be connected to the SMF 174 via the N10 interface. Similarly, the UDM 197 may be connected to the AUSF 190 via the N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0230] The AUSF 190 performs operations related to authentication and is connected to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0231] NEF 196 exposes the functions and services in 5G core network 109 to application function (AF) 188. The exposure can occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface, and it can be connected to other network functions to expose the functions and services of 5G core network 109.

[0232] The application function 188 may interact with the network function in the 5G core network 109. The interaction between the application function 188 and the network function may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

[0233] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables operators to create networks tailored to provide optimized solutions for different market scenarios that require different requirements (for example, in terms of functionality, performance and isolation).

[0234] 3GPP has designed the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a variety of 5G use cases that require very diverse and sometimes extreme requirements (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband). Without the use of network slicing technology, when each use case has its own specific set of performance, scalability, and availability, the network architecture may not be flexible and scalable enough to efficiently support a wide range of use case requirements. In addition, the introduction of new network services should be made more efficient.

[0235] Reference again Fig.23 In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via the N1 interface. The AMF may logically be part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0236] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include, or may communicate with, an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include, or may communicate with, a short message service (SMS) service center that facilitates communications via a short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and a server or application function 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0237] This article describes and Fig. 20 , 22 The core network entities shown in , 23 and 24 are identified by the names given to those entities in certain existing 3GPP specifications, but it will be appreciated that those entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig. 20 , 21 The specific network entities and functions described and illustrated in , 22, 23 and 24 are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or defined in the future.

[0238] Fig.24 An example communication system 111 is illustrated in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may not be within the coverage of the access network 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0239] If WTRUs A, B, C, D, E, and F are within access network coverage 131, they may communicate with each other via gNB 121 over the Uu interface 129. Fig.24In the example of FIG. 1 , WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate directly with each other via a sidelink interface (e.g., PC5 or NR PC5) such as interface 125a, 125b, or 128, whether they are within or outside access network coverage 131. For example, in Fig.24 In the example of , WTRU D outside the access network coverage 131 communicates with WTRU F within the coverage 131.

[0240] WTRUs A, B, C, D, E, and F may communicate with the RSU 123a or 123b via the vehicle-to-network (V2N) 133 or the sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate with the V2X server 124 via the vehicle-to-infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate with another UE via the vehicle-to-person (V2P) interface 128.

[0241] Fig.25 is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatus described herein, such as Fig. 20 , 21 , 22, 23 or 24. Fig.25 As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. Moreover, the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node B gateway, a next generation node-B (gNode B), and a proxy node, etc.), may include Fig.25 Some or all of the elements depicted in and described herein.

[0242] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.25 The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0243] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Fig. 20 The transmission / reception element 122 may be a base station 114a) of a wireless communication network, or may transmit or receive signals to or from another UE via an air interface 115d / 116d / 117d. For example, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. The transmission / reception element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. The transmission / reception element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0244] In addition, although the transmit / receive element 122 is Fig.25 Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0245] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA) or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0246] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server hosted in a cloud or edge computing platform or in a home computer (not shown).

[0247] The processor 118 may receive power from the power source 134 and may be configured to distribute power to and / or control other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0248] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method.

[0249] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0250] The WTRU 102 may be included in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes, etc.) The WTRU 102 may be connected to other components, modules or systems of such devices or equipment via one or more interconnect interfaces (such as an interconnect interface that may include one of the peripheral devices 138).

[0251] Fig.26 is a block diagram of an exemplary computing system 90 in which Fig. 20 , 22 , 23 and 24, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever or in any manner such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to enable the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0252] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path, system bus 80. Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0253] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that translates a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0254] In addition, the computing system 90 may include a peripheral device controller 83 that is responsible for transmitting instructions from the processor 91 to peripheral devices such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0255] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0256] Additionally, computing system 90 may include communications circuitry such as, for example, a wireless or wired network adapter 97, which may be used to connect computing system 90 to an external communications network or device (such as a wireless or wired network adapter 97). Fig. 20 , 21, RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102 or other network 112 of 104, 22, 23 and 24 to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit system can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

[0257] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassette, tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

Claims

1. An apparatus comprising a processor, a memory, and a communication circuit system, the apparatus being configured to communicate via the communication circuit system, the apparatus further comprising computer executable instructions stored in the memory of the apparatus, the computer executable instructions, when executed by the processor of the apparatus, causing the apparatus to: receiving system information from a first network, the system information relating to network support for restricted access for network selection assistance; sending a registration request to the first network, the registration request signaling a limited registration; Send a manual network selection request; receiving, via the first network, a manual network selection response, the manual network selection response comprising PLMN information; Log out of the first network; and Register with the second network.

2. The apparatus of claim 1, wherein the registration request further signals support for non-coverage related network transfer.

3. The apparatus of claim 1, wherein the manual network selection request includes a list of found networks. The apparatus of claim 3 , wherein the second network is selected from a list of found networks.

5. The apparatus of claim 3, wherein the manual network selection request further comprises a received signal strength associated with each found network.

6. The apparatus of claim 3, wherein the manual network selection request further comprises a cell identity of the strongest cell associated with each found network.

7. The apparatus of claim 3, wherein the manual network selection request is sent in a non-access stratum message.

8. The apparatus of claim 3, wherein the manual network selection request is sent to a policy control function.

9. The apparatus of claim 3, wherein the manual network selection request is sent to a server via a restricted local operator service (RLOS) connection using Internet Protocol (IP) based communications.

10. The apparatus of claim 3, wherein the registration request includes information indicative of the manual network selection request.

11. The apparatus of claim 10, wherein the manual network selection response includes an indication of a time window for performing registration with the second network.

12. A method performed by a device comprising a processor and a memory, the method comprising: receiving system information from a first network, the system information relating to network support for restricted access for network selection assistance; sending a registration request to the first network, the registration request signaling a limited registration; Send a manual network selection request; receiving, via the first network, a manual network selection response, the manual network selection response comprising PLMN information; Log out of the first network; and Register with the second network.

13. The method of claim 12, wherein the registration request further signals support for non-coverage related network transfer.

14. The method of claim 12, wherein the manual network selection request includes a list of found networks.

15. The method of claim 14, wherein the second network is selected from a list of found networks.

16. The method of claim 14, wherein the manual network selection request further includes a received signal strength associated with each found network.

17. The method of claim 14, wherein the manual network selection request is sent in a non-access stratum message.

18. A non-transitory computer-readable storage medium having computer-executable instructions stored thereon, the computer-executable instructions, when executed by one or more processors, causing the one or more processors to perform operations comprising: receiving system information from a first network, the system information relating to network support for restricted access for network selection assistance; sending a registration request to the first network, the registration request signaling a limited registration; Send a manual network selection request; receiving, via the first network, a manual network selection response, the manual network selection response comprising PLMN information; Log out of the first network; and Register with the second network.

Images