CN116868641A

CN116868641A - Method, apparatus and system for service interruption Minimization (MINT)

Info

Publication number: CN116868641A
Application number: CN202280014370.3A
Authority: CN
Inventors: 贝洛兹·阿加里; 萨米尔·费尔迪; 阿莱克·布鲁西洛夫斯基; 萨阿德·艾哈迈德
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2021-01-14
Filing date: 2022-01-12
Publication date: 2023-10-10

Abstract

Methods, apparatus, and systems are disclosed. In one embodiment, a method implemented by a wireless transmit/receive unit (WTRU) registered with a first network is disclosed, the method comprising: receiving information from the first network indicating a value to be used during registration with the second network; and determining at least a first start time and a second start time from which to perform the registration with the second network based on at least the indicated value. The method further comprises the steps of: initiating the registration with the second network after the first start time; and on condition that the registration is not completed within a defined period after the first start time: (1) Suspending the registration with the second network, and (2) initiating a second registration or re-registration of the WTRU with the second network after the second start time.

Description

Method, apparatus and system for service interruption Minimization (MINT)

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional application number 63/185,474 filed on day 5 and 7 of 2021, U.S. provisional application number 63/172,936 filed on day 4 and 9 of 2021, U.S. provisional application number 63/150,283 filed on day 2 and 17 of 2021, and U.S. provisional application number 63/137,531 filed on day 1 and 14 of 2021, each of which is incorporated herein by reference.

Technical Field

Embodiments disclosed herein relate generally to wireless communications and, for example, relate to methods, apparatuses, and systems for service disruption minimization.

Background

The network sometimes experiences failures and/or disasters.

Drawings

A more detailed understanding can be obtained from the following detailed description, which is given by way of example in connection with the accompanying drawings. The drawings in the present specification are examples. Accordingly, the drawings and detailed description are not to be regarded as limiting, and other equally effective examples are possible and contemplated. In addition, like reference numerals in the drawings denote like elements, and wherein:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A according to one embodiment;

Fig. 2 is a diagram illustrating a disaster response scenario whereby a Disaster Response Function (DRF) enables notification to WTRUs and roaming partners of the onset of a disaster condition and authorization of a WTRU to register in a PLMN without a disaster condition;

fig. 3 is a diagram illustrating a disaster response scenario whereby the DRF enables WTRUs and roaming partners to be notified of the end of a disaster condition;

fig. 4 is a diagram showing a registration procedure with a roaming PLMN without disaster condition in case of disaster condition;

FIG. 5 is a diagram illustrating a representative process for disaster roaming using DRID;

FIG. 6 is a diagram illustrating a representative process for determining when to perform registration with the HPLMN after a disaster (e.g., disaster condition);

fig. 7 is a diagram illustrating a representative registration process;

fig. 8 is a flow chart illustrating a representative method implemented by a WTRU;

fig. 9 is a flow chart illustrating another exemplary method implemented by a WTRU;

fig. 10 is a flowchart illustrating an additional exemplary method implemented by a WTRU;

fig. 11 is a flow chart illustrating another exemplary method implemented by a WTRU;

fig. 12 is a flow chart illustrating yet another exemplary method implemented by a WTRU;

fig. 13 is a flow chart illustrating yet another exemplary method implemented by a WTRU;

Fig. 14 is a flow chart illustrating a further additional exemplary method implemented by a WTRU;

fig. 15 is a flow chart illustrating yet another additional exemplary method implemented by a WTRU; and is also provided with

Fig. 16 is a flow chart illustrating a representative method implemented by a network entity.

Detailed Description

Exemplary network for implementing embodiments

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter Bank Multicarrier (FBMC), and the like.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, public Switched Telephone Networks (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the internet 110, and/or the other networks 112. As an example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs (enbs), home Node Bs (HNBs), home evolved node bs (henbs), gnbs, NR node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104/113 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as noted above, 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, or the like. For example, a base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c 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.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or High Speed UL Packet Access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a new air interface (NR) to establish the air interface 116.

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., enbs and gnbs).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106/115.

The RANs 104/113 may communicate with the CNs 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RANs 104/113 and/or CNs 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RANs 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 that may utilize NR radio technology, the CN 106/115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA, wiMAX, E-UTRA, or WiFi radio technology.

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RANs 104/113 or a different RAT.

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

Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the 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 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

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 in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Although the transmit/receive element 122 is depicted as a single element in fig. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, 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 116.

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 noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to 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 battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to a 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 information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photographs and/or video), universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, wireless communications devices, and the like,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.

The processor 118 of the WTRU 102 may be in operable communication with various peripherals 138, including, for example, any of the following: one or more accelerometers, one or more gyroscopes, a USB port, other communication interfaces/ports, a display, and/or other visual/audio indicators.

WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit for reducing and/or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).

Fig. 1C is a system diagram illustrating a RAN 104 and a CN 106 according to an embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with CN 106.

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, 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 UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

MME 162 may be connected to each of evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.

The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).

In representative embodiments, the other network 112 may be a WLAN.

A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a width dynamically set by signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, via a combination of a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. Streams may be mapped onto the two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).

The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).

WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA (supporting only 1MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and possibly available.

The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Fig. 1D is a system diagram illustrating a RAN 113 and a CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over an air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 113 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, gnbs 180a, 180b may utilize beamforming to transmit signals to gnbs 180a, 180b, 180c and/or to receive signals from gnbs 180a, 180b, 180 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from one transmission to another, from one cell to another, and/or from one portion of the wireless transmission spectrum to another. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c while also communicating or connecting with another RAN (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c 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 UL and/or DL, support of network slices, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

The CN 115 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

AMFs 182a, 182b may be connected to one or more of gNB 180a, 180b, 180c in RAN 113 via an N2 interface and may function as a control node. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency communication (URLLC) access, services relying on enhanced mobile (e.g., large-scale mobile) broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. AMF 182 may provide control plane functionality for switching between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi.

The SMFs 183a, 183b may be connected to AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. SMFs 183a, 183b may select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning WTRU IP (e.g., UE IP) addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.

UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b through an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-102d, base stations 114a-114B, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMFs 182a-182B, UPFs 184a-184B, SMFs 183a-183B, DNs 185a-185B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.

The simulation device may be designed to enable one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more emulation devices can perform one or more or all of the functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and/or may perform testing using over-the-air wireless communications.

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test laboratory and/or a test scenario in a non-deployed (e.g., test) wired and/or wireless communication network in order to enable testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and/or receive data.

In some representative embodiments, the WTRU may use a timer (e.g., along with its own identity) provided by the Network (NW) (e.g., a network entity) in the registration accept to derive a window through which the WTRU may perform or will perform registration with the new network (e.g., via the new network entity).

In some representative embodiments, during the registration procedure, the NW may inform the WTRU of an identity (e.g., a "special ID") that the NW may use or will use when one or more disaster conditions apply. For example, the NW may provide the WTRU with a string (e.g., a code) for protection or for security, which may be used locally by the WTRU along with a broadcast ID and known algorithms, which may then result in a permanent IE (e.g., subscription permanent identity (SUPI)/International Mobile Equipment Identity (IMEI) for the WTRU.

In some representative embodiments, the RAN may provide information by the CN to block/defer RRC connection for inbound (e.g., disaster) WTRUs. When sending the RRC connection request, the WTRUs may use the new establishment cause. The RAN may provide a timer in RRC connection rejection that may delay/defer a new connection of the WTRU to a later time slot, for example. To further randomize the delay period for connection retries, the WTRU may use a formula based on the timer value and its own ID.

In some representative embodiments, the WTRU may receive a disaster response event ID (DRID) when registering with PLMN D (e.g., prior to a disaster condition). When a disaster condition occurs, the WTRU may select a PLMN (e.g., PLMN a) based on the matching DRID broadcast by the PLMN (e.g., PLMN a). The WTRU may register with PLMN a for inbound roaming and may provide DRID for authorization by the HPLMN for inbound roaming.

In some representative embodiments, when registered in a PLMN (e.g., PLMN D) (which may be, for example, a HPLMN in general), when the WTRU and the AMF exchange information that both support the mit and the AMF provides a tracking area list (e.g., a TAI list), the WTRU may inform the AMF when the WTRU enters a new TA (e.g., each time or each time it enters a new Tracking Area (TA), even if the new TA is or may be part of the TAI list. The WTRU does this, for example, by: (1) modify one or more existing NAS messages (such as service requests), (2) send new NAS messages, and/or (3) perform mobility registration updates, etc.

PLMN D herein may generally refer to a PLMN having/experiencing or will have/experience the following associated disaster conditions: (1) previously notified and/or set; (2) to be notified/set; and/or (3) currently notified/set. For example, PLMN D may be powered down (e.g., resulting in lack of operation of the network within some or all of the associated PLMN coverage area), or PLMN D may have some other disruption to the network in some or all of the associated PLMN coverage area. PLMN D may be a home PLMN or a visited PLMN. PLMN a herein may refer generally to another PLMN and may be able or unable to accept an inbound roaming WTRU registered or attempting to register with, for example, PLMN D with and/or experiencing a disaster condition.

Certain representative embodiments may be applicable to disaster events somewhere in the network (e.g., such as fire events in the building in which certain network nodes and components reside).

In some representative embodiments, the WTRU may receive one or more allowed regional level DRIDs when registering with a PLMN (e.g., PLMN D) (prior to the disaster condition). For example, the DRID may consist of or may include the following: PLMN ID (MCC, MNC), area ID (AID), and/or Disaster Recovery Code (DRC) (e.g., drid=plmn id+aid+drc). The AID may identify a geographic area that maps a portion of a coverage area of the PLMN (e.g., NG-RAN coverage area of PLMN D) (e.g., associated with or including one or more NG-RAN nodes and/or one or more Tracking Areas (TAs), etc.). The WTRU may select another PLMN (e.g., PLMN a) based on the DRID broadcast by PLMN a or a portion (e.g., DRC) of the DRID matching one or more allowed DRIDs indicated by PLMN D. The WTRU may register with other PLMNs (e.g., PLMN a) for inbound roaming and may provide a matching protected DRID for authorization by the HPLMN for inbound roaming.

In some representative embodiments, the WTRU may be configured (e.g., by the HPLMN) with one or more allowed regional level DRIDs and/or allowed PLMN level DRIDs associated with a given PLMN (e.g., PLMN D as the HPLMN of the WTRU). PLMN level DRID components/parts may be similar to area specific DRIDs, except that the AID may identify a geographic area mapping the entire PLMN. The regional DRID components/parts may be similar to the regional specific DRID, except that the AID may identify a geographic region that maps a portion (e.g., a broad area) of the coverage (e.g., city, state, and/or province) of the PLMN. When disaster inbound roaming is performed, the regional DRID may be used by the WTRU/PLMN as an intermediate level of granularity between the regional DRID and the PLMN-level DRID. When affected by a disaster condition, PLMN a may accept disaster inbound roamers in all or part of such regions (e.g., may begin broadcasting one or more associated regional level DRIDs based on information received from PLMN D and/or local authorities). The WTRU may select a PLMN (e.g., PLMN a) based on a match of the DRID with an allowed regional or PLMN level DRID or a match of a portion of the DRID broadcast by PLMN a (e.g., mcc+drc) with an allowed regional or PLMN level DRID. The WTRU may register with PLMN a for inbound roaming, providing a protected regional or PLMN level DRID for authorization by the HPLMN for inbound roaming.

In certain representative embodiments, methods, systems, apparatus, and processes may be implemented for notifying a WTRU of a disaster condition. For example, methods, systems, apparatus, and processes may be implemented to deliver/send information regarding disaster conditions for PLMNs in an area to WTRUs located in the area. As another example, methods, systems, apparatus and processes may be implemented to integrity protect, reproduce protect and/or confidentiality protect information of disaster conditions of PLMNs. As a third example, the methods, systems, apparatuses, and processes may be implemented to determine, for example, the type/kind of information to be delivered/sent to the WTRU based on, for example, any of the following: disaster conditions, number of WTRUs affected by the disaster conditions, services/applications performed on the WTRUs, network slices used by the WTRUs, mobility of the WTRUs (e.g., connection capabilities of the WTRUs), capabilities of the WTRUs (e.g., other connection capabilities, bluetooth, WLAN, WIFI, etc.).

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to provide an indication to the WTRU of accessibility from PLMNs (e.g., other PLMNs without disaster conditions). For example, one or more other PLMNs (e.g., other PLMNs than the disaster-conditioned PLMN) may indicate (e.g., each indicate) that the corresponding PLMN may accommodate an inbound roamer (e.g., an inbound roamer from the disaster-conditioned PLMN, sometimes referred to herein as an Inbound Disaster Roamer (IDR) or IDR WTRU).

Representative procedure for registration with roaming PLMN without disaster condition

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to perform a registration procedure initiated by a DIR (e.g., an IDR WTRU).

In certain representative embodiments, methods, systems, apparatuses, and processes may be implemented to authenticate an IDR. For example, the home network may not be available for "normal" roaming authentication and authorization) the WTRU. It is contemplated that such a WTRU may sometimes be referred to as a civilian WTRU. For example, a civilian WTRU (e.g., all "civilian WTRUs") may be any one of the following: (1) One or more non-roaming WTRUs with a serving network that may be the same as their home network (e.g., the WTRUs may not roam or be unable to roam to another PLMN because the CN is unable to authenticate them). This may occur when a primary database (e.g., universal Data Management (UDM)/Home Subscriber Server (HSS)) in the home PLMN is not reachable, and/or (2) one or more inbound roaming WTRUs that may roam to and be authenticated on other PLMNs.

In some demonstrative embodiments, methods, apparatuses and processes may be implemented to register a WTRU in a PLMN (e.g., PLMN a) providing service to an inbound roamer when a disaster occurs in the PLMN (PLMN D) during or just prior to registration in PLMN D.

In certain representative embodiments, methods, systems, apparatus, and processes may be implemented to enable PLMNs (e.g., disaster PLMNs or disaster roaming PLMNs) to limit service areas for IDR WTRUs to areas where disaster conditions apply.

In some representative embodiments, methods, systems, apparatus, and processes may be implemented to allow a WTRU that does not seek to complete registration in PLMN D (e.g., because a catastrophic condition occurred in PLMN D during or just prior to registration) to register in another PLMN (e.g., PLMN a) that may provide service to an inbound roamer.

In certain representative embodiments, methods, systems, apparatus, and processes may be implemented to ensure that inbound roamers reside (e.g., actually reside) in the disaster area of PLMN D when a disaster occurs.

Representative procedure for informing disaster conditions no longer applicable to a WTRU

In certain representative embodiments, methods, systems, apparatus, and processes may be implemented to deliver/transmit (and/or when) information that disaster conditions no longer apply to one or more IDR WTRUs.

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to cause one or more IDR WTRUs to perform network selection when notified that the disaster condition is no longer applicable.

Representative procedure for preventing signaling overload in PLMNs without catastrophic conditions

In some representative embodiments, methods, systems, apparatus, and processes may be implemented to stagger the arrival of WTRUs in PLMNs that are not disaster-free, e.g., to extend registration attempts over time and/or to keep the number of WTRUs attempting to register simultaneously within manageable limits (e.g., threshold levels).

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to enable a PLMN to prevent (e.g., effectively prevent) the IDR WTRU from attempting to register on the PLMN when the PLMN without a disaster condition is no longer able to accept the IDR WTRU (e.g., due to congestion).

Representative procedure for preventing signaling overload by returning a WTRU to a previous disaster-conditioned PLMN

In some representative embodiments, methods, systems, apparatus, and processes may be implemented to stagger the return of WTRUs to PLMNs that were previously disaster-conditioned, e.g., to extend registration attempts over time and/or to keep the number of WTRUs attempting to register simultaneously within manageable limits (e.g., threshold levels).

Representative procedure for outbound roam WTRU

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to provide notification to the outbound WTRUs about the disaster in their Home Networks (HNs).

In some demonstrative embodiments, methods, systems, devices and processes may be implemented to enable an outbound WTRU to get (e.g., perform) reauthentication in a Serving Network (SN) during outbound roam. For example, an AT & T WTRU may roam on another network (China Mobile (CMCC) network) of the People's Republic (PRC), if there is a disaster condition (e.g., AT & T UDM fire) in its HN, the WTRU may (re) register.

Representative for disaster response managementArchitecture/implementations

In certain representative embodiments, a network function, referred to herein as a Disaster Response Function (DRF), may be implemented. For example, the DRF may provide abstraction (abstraction) to the rest of the 3GPP system to support disaster response management functionality/processes/operations. Some of the DRF functionality/processes/operations may be co-located with existing functions (e.g., UDM and/or Policy Control Function (PCF), etc.). The DRF may include support for the following functionality/processes/operations (e.g., provided on a service-based architecture and/or via a user plane), including any of the following:

(1) Support for maintaining information related to disaster conditions, including, for example: (i) the start of the disaster condition (e.g., start time/date), (ii) the end of the disaster condition, (iii) the area in which the disaster condition applies, (iv) a list of roaming partner PLMNs in the same country that support IDR WTRUs, (v) a list of affected WTRUs (e.g., it is contemplated that triggers for the start or end of the disaster condition may be provided by functions/devices external to the DRF (e.g., by a Mobile Network Operator (MNO) network management system).

(2) Selecting the start and/or end of the disaster condition and/or notifying the relevant roaming partners of the start and/or end of the disaster condition (e.g., a DRF in or associated with the affected PLMN may inform one or more DRFs in or associated with one or more other PLMNs that are not in the disaster condition and may provide information about the area affected by the disaster condition).

(3) Select a start and/or end of a disaster condition, and/or notify a WTRU (e.g., of the disaster condition encountered or later as an IDR WTRU) of the start and/or end of the disaster condition to an associated Network Function (NF) within the PLMN with and without the disaster condition.

For example, the DRF may be any of the following:

(i) In or associated with the disaster-conditioned PLMN, notifying the AMF of the start/end of the disaster condition to thereby notify the affected WTRU and/or NG-RAN;

(ii) In or associated with a PLMN without a disaster condition, a disaster affected area (e.g., geographic coordinates) may be mapped from the affected PLMN to the cell area and one or more serving AMFs, and/or the one or more AMFs may be notified of the start/end of the disaster condition, which in turn may inform the IDR WTRU and/or NG-RAN accordingly.

(4) The serving NF registration management of IDR WTRUs in PLMNs without disaster conditions may store the serving AMF in PLMNs without disaster conditions for roaming WTRUs.

(5) Access authorization for an IDR WTRU is supported based on information related to a disaster condition (e.g., whether a particular WTRU is allowed to register due to disaster roaming (e.g., a DRF may determine/check whether the disaster condition applies to WTRUs in a given area and/or may check/determine whether to limit the number of IDR WTRUs (e.g., based on a limit/threshold on the number of allowed IDR WTRUs)).

(6) The DRF may control (e.g., be responsible for) assigning identities related to disaster management functionality. For example, a particular disaster condition may be assigned a unique event id by the DRF (e.g., unique within the affected PLMN). For PLMN selection supporting an IDR WTRU, the event id may be used to correlate the beginning and/or end of a particular disaster condition. The same PLMN may be subject to one or more disaster conditions (e.g., in different regions), and the DRF may thus be assigned different event ids (e.g., based on various impacted areas). When disaster conditions are applicable, WTRUs performing inbound disaster roaming may be assigned an inbound roaming id that may be used to track inbound roamers (e.g., for updates/notifications regarding disaster conditions) for billing purposes.

Fig. 2 is a diagram illustrating a disaster response scenario 200 whereby a DRF may enable notification to a WTRU and roaming partners of the onset of a disaster condition and authorization of the WTRU to register with a PLMN that is not disaster condition (e.g., does not itself experience a disaster condition, e.g., to inform the WTRU of the onset of a disaster condition in another PLMN and/or to select and register the WTRU with such PLMN that is not disaster condition).

Referring to fig. 2, a first PLMN 205D (e.g., PLMN #1 and/or source PLMN) may have, may use, may be serviced by, and/or may be associated with: the first DRF 210D, the first AMF 182D, and/or the first Next Generation (NG) radio access network (NG-RAN) 220D. The second PLMN 205A (e.g., PLMN #2 and/or target PLMN) may have, may use, may be serviced by, and/or may be associated with: a second DRF 210A, a second AMF 182A, and/or a second NG-RAN 220A). The first PLMN 205D may be experiencing or determined to have a disaster condition and the second PLMN 205A (e.g., PLMN # 2) may not be experiencing or determined to have no disaster condition. For example, the first DRF 210D may be a DRF associated with the source PLMN 205D serving the WTRU 102). For example, the second DRF 210A may be a DRF associated with a target PLMN 205A that may subsequently serve the WTRU 102.

At operation 2-0, the disaster detection system/entity 230 may send information to the first DRF 210D indicating a disaster start event associated with the first PLMN 205D and an area/location of the first PLMN 205D associated with the event. At operation 2-1a, the first DRF 210D can communicate with a second DRF 210A (e.g., at least one DRF) to provide information indicative of a disaster start event including, for example, event identification and/or an area/location associated with the event. At operation 2-1b, the first DRF 210D may communicate with the first AMF 182D to provide information indicative of a disaster start event including, for example, event identification and/or an area/location associated with the event.

At operation 2-2A, the target DRF 210A may send information to the second AMF 182A indicating a disaster start event associated with the first PLMN 205D, the disaster start event including an area/location associated with the event, an event identification associated with the disaster start event, and/or a PLMN identification associated with the first PLMN 205D (e.g., a PLMN experiencing/having a disaster condition). At operation 2-2b, the first AMF 182D may send information to the first NG-RAN 220D indicating a paging and/or broadcast disaster condition, the disaster condition including an event identification.

At operations 2-3a, the second AMF 182A may send information to the NG-RAN 220A indicating broadcast disaster inbound roaming support including an event identification and/or a PLMN identification associated with the first PLMN 205D. At operations 2-3b, the first NG-RAN 220D may page and/or begin broadcasting a disaster condition to the WTRU 102, the disaster condition including an event identification and/or a flag.

At operations 2-4a, the second NG-RAN 220A may begin broadcasting disaster inbound roaming support including an event identification and/or PLMN identification (e.g., mobile Country Code (MCC) and/or mobile network operator (MNC)) associated with the first PLMN 205D. At operations 2-4b, the first AMF 182D and the WTRU 102 may communicate information to register the WTRU 102 with the first PLMN 205D. The information may indicate disaster recovery parameters including, for example, any of the following: (1) one or more authorized PLMNs for disaster inbound roaming, (2) a disaster roaming registration time value (e.g., registration timer value), (3) a DRF Fully Qualified Domain Name (FQDN), and/or (4) event identification, etc.

At operations 2-5A, the WTRU 102 may select a second PLMN 205A (e.g., as the target PLMN) based on an event identification associated with the disaster event. At operations 2-6, the WTRU 102 and the second AMF 182A may communicate. For example, the WTRU 102 may send registration information to the second AMF 182A to register the WTRU 102. The registration information may indicate any of the following: (1) connection cause (e.g., disaster inbound roam), (2) access identity, and/or (3) event identification, etc. After or in response to the transmitted registration information, the second AMF 182A may transmit any one of the following to the WTRU 102: (1) mobility restriction information for disaster inbound access, (2) return registration values (e.g., return registration timer values) and/or (3) inbound roamer identification, etc.

At operations 2-6', the second DRF 210A and/or the second AMF 182A may invoke inbound disaster roaming access authorization for the WTRU 102 and/or AMF registration with the second DRF 210A. For example, the second DRF 210A and the second AMF 182A may communicate, and the second AMF 182A may send an authorization/registration message (e.g., a disaster roaming authorization/registration message) to the second DRF 210A, the message including information indicating any one of: (1) WTRU ID, (2) MCC and/or MNC, (3) registration area, and/or (4) event identification, etc. After or in response to the authorization/registration message, the second DRF 210A may send information indicating that the authorization/registration was successful or that the authorization/registration failed and the inbound roamer identification. At operations 2-7, the WTRU 102 and the first DRF 210D may communicate to re-register the WTRU 102 with the first PLMN 205D (e.g., after the disaster condition ends). For example, the WTRU 102 may send an inbound roamer registration message to the first DRF 210D indicating any one of the following: (1) WTRU ID, (2) inbound rover identification, (3) event identification, and/or (4) location of WTRU 102, etc.

In certain representative embodiments, the AMF 182D may interact directly with a source DRF 210D (S-DRF) in a PLMN 205D (e.g., home PLMN (HPLMN)) with a disaster condition (e.g., in a shared RAN infrastructure with common cell areas). In some embodiments, the WTRU 102 may register with the DRF 210 through the user plane to receive direct notifications/updates regarding the disaster condition (e.g., via the end of the disaster condition notification, and/or an indication of when to reselect/re-register back to the PLMN 205A under the disaster condition, etc.). For WTRUs 102 that may not have a user plane (user plane connection), the WTRU 102 may be able to register with the DRF 210 using a Control Plane (CP) PDU session. For example, the DRF 210 may send one or more indications and/or information to the WTRU 102 via a CP PDU session. In some representative embodiments, the WTRU 102 may interact with the DRF 210 through a Control Plane (CP) using NAS signaling that conveys the disaster management message container. In some representative embodiments, the WTRU 102 may receive a list of PLMNs 205D and 205A, etc. that are authorized for Inbound Disaster Roaming (IDR) for use in the event of a disaster condition. WTRU 102 may receive the IDR ID during this process to enable IDR PLMN selection when performing inbound disaster roaming. The WTRU 102 may receive this information (using PLMN #1 in fig. 2) during a registration or WTRU configuration procedure. The first PLMN 205D (e.g., PLMN # 1) may periodically generate a new IDR ID to the registered WTRU 102 and IDR PLMN partners. The IDR PLM partner may associate the IDR ID with a PLMN #1ID, e.g., a Mobile Country Code (MCC) and/or a mobile network operator (MNC). The IDR ID may be used as a pseudonym for the PLMN ID to maintain confidentiality of the PLMN 205A when a disaster condition is experienced (e.g., the IDR ID may be associated with one or more event IDs that track a particular event, as shown in fig. 2). For example, when the WTRU 102 detects a disaster condition in the first PLMN 205D (e.g., PLMN #1 in fig. 2) (e.g., from an indication in a broadcast or paging message, or by detecting the absence of the first PLMN cell, or due to an abnormal deregistration from the first PLMN 205D), the WTRU 102 may initiate a PLMN selection procedure using the above list of PLMNs 205 authorized for inbound disaster roaming, and may select such cells (e.g., in the second PLMN 205A (e.g., PLMN #2 in fig. 2) on the condition that the cells broadcast matching IDR IDs.

Fig. 3 is a diagram illustrating a disaster response scenario 300 whereby the DRF enables notification to the WTRU and roaming partners of the end of a disaster condition (e.g., to inform the WTRU of the end of the disaster condition and/or to return to a PLMN previously with the disaster condition).

Referring to fig. 3, a first PLMN 205D (e.g., PLMN # 1) may have, may use, may be serviced by, and/or may be associated with: the first DRF 210D, the first AMF 182D, and/or the first Next Generation (NG) radio access network (NG-RAN) 220D. The second PLMN 205A (e.g., PLMN # 2) may have, may use, may be serviced by, and/or may be associated with: a second DRF 210A, a second AMF 182A, and/or a second NG-RAN 220A). The first PLMN 205D may: (1) Has previously experienced or (2) has been determined to have previously experienced a disaster condition (e.g., it has now ended). The second PLMN 205A (e.g., PLMN # 2) may: (1) not experiencing, (2) not previously experiencing, (3) determined to not have experienced; and/or (4) determined to have not previously experienced a disaster condition. For example, the first DRF 210D may be a DRF associated with a first PLMN 205D that has previously served the WTRU 102 prior to the disaster condition. For example, the second DRF 210A may be a DRF associated with a second PLMN 205A that may subsequently serve the WTRU 102 after the end of the disaster condition. The procedure may be used to re-register the WTRU 102 with the first PLMN 205D after the end of the disaster condition in the first PLMN 205D.

At operation 3-0, the disaster detection system/entity 230 can send information to the first DRF 210D indicating the disaster end event associated with the first PLMN 205D and the area/location of the first PLMN 205D associated with the event. At operation 3-1a, the first DRF 210D may communicate with the first AMF 182D to provide information indicative of a disaster end event including, for example, event identification and/or an area/location associated with the event. At operation 3-1b, the first DRF 210D can communicate with a second DRF 210A (e.g., at least one DRF) to provide information indicative of a disaster end event including, for example, event identification and/or an area/location associated with the event.

At operation 3-2a, the first AMF 182D may send information to the first NG-RAN 220D indicating to stop paging and/or broadcast a disaster condition including an event identification. At operation 3-2b, the target DRF 210A may send information to the second AMF 182A indicating a disaster end event associated with the first PLMN 205D, the disaster end event including an area/location associated with the event and/or an event identification associated with the disaster end event for the first PLMN 205D. For example, this information may be indicated as follows: (1) Per region/location and/or (2) per WTRU (e.g., with or without rate limiting, e.g., to reduce congestion of the WTRU 102 transitioning back to the first PLMN 205D).

At operation 3-3a, the first NG-RAN 220D may cease paging and/or cease broadcasting information to the WTRU 102 indicating a disaster condition. At operation 3-3b, the second AMF 182A may send information to the NG-RAN 220A indicating to stop broadcasting disaster inbound roaming support including event identification of the disaster end event.

At operations 3-4b, the second NG-RAN 220A may cease broadcasting information indicating disaster inbound roaming support. At operations 3-5, the second AMF 182A and the WTRU 102 may communicate information to de-register the WTRU 102 with the second PLMN 205A. The log-off information from the second AMF 182A may indicate a disconnect cause (e.g., end of disaster). At operations 3-5', a procedure may be invoked to deregister the second AMF 182A from the second DRF 210A and may end the inbound roaming registration of the WTRU 102 with the second PLMN 205A. For example, at operations 3-5', a disaster inbound roam cancellation procedure may be completed in which the second AMF 182A may send information to the second DRF 210A indicating any one of: (1) AMF ID, (2) WTRU ID (e.g., SUPI and/or MCC/MNC), and/or (3) registration area, etc. The second DRF 210A may send information indicating a successful logout.

At operations 3-6, the first DRF 210D may send notification information to the WTRU 102 indicating the end of the inbound roamer disaster and may include an event identification and/or a return time value (e.g., a return timer value). At operations 3-7, the WTRU 102 may reselect to the first PLMN 205D if the PLMN does not have an event id associated with a persistent disaster (e.g., current disaster condition). At operations 3-8, the first AMF 182D and the WTRU 102 may communicate information to register (e.g., re-register) the WTRU 102 back to the first PLMN 205D. The timing of registration may be based on the return time value.

In some representative embodiments, the AMF may interact directly with an S-DRF in a PLMN that was previously in a disaster condition, rather than with a target DRF (T-DRF). In some embodiments, the WTRU may receive a direct notification of the disaster condition from the DRF through the user plane (e.g., via the end of the disaster condition notification, and/or an indication of when to reselect/re-register back to a PLMN under the disaster condition, etc.). The WTRU may be de-registered by the AMF from a PLMN that does not indicate the following disaster conditions: (1) End of disaster condition, and/or (2) parameters to control when the WTRU may register back with the PLMN under disaster condition.

In both scenarios shown in fig. 2 and 3, the WTRU may receive an indication from the AMF in a registration accept message when registering its HPLMN (e.g., PLMN 1) informing the WTRU that the WTRU may establish or need to establish a user plane connection with the DRF. The registration accept message may include information for connecting to the DRF (e.g., IP address, FQDN, DRF name, DNN, etc.). The information may be included or contained in a policy container in the registration accept message. The WTRU may receive an indication to connect to the DRF and corresponding DRF information, e.g., via a WTRU Configuration Update (WCU) procedure initiated by a network (e.g., a network entity or network function), either before or after registration.

Representative procedure for informing a WTRU of a disaster condition

In some representative procedures, paging may be used to notify the WTRU of a disaster condition. In some embodiments, during the registration process, a network (e.g., an AMF in a 5G independent system) may inform the WTRU of an identity (e.g., a "special ID") that the Network (NW) may use in paging messages when paging the WTRU. To protect against an attacker, the network may provide a "string" (e.g., a code) to the WTRU, which may be used locally by the WTRU along with the broadcast ID and known algorithms, which may result in a permanent ID (e.g., SUPI/IMEI) for the WTRU. Another way to protect against an attacker may be to provide the network with a set of multiple special IDs/numbers (instead of just one) to the WTRU. Using this procedure, the network may use any of these IDs/numbers in the paging message, and if the WTRU detects a match between the ID/number used in the paging message and any of the IDs/numbers it received from the NW during the registration procedure, the WTRU may interpret the paging message as indicating a disaster condition. After one of the members of the ID/number set is used, the WTRU may remove the ID/number and may treat such number as being received again in a paging message (e.g., a subsequent paging message) as anomalous (e.g., and may remove the anomaly, report the anomaly, and/or save the anomaly for further reporting). In order for the above-described concept to be viable, the NW may send (e.g., must send) the same ID over all paging occasions over a period long enough (e.g., a long time interval) to ensure that WTRUs in the area (e.g., all WTRUs) are able to receive and determine the ID and to thereby determine that the disaster condition applies.

In other embodiments, cell broadcast and/or MBMS may be used to notify WTRUs of a disaster condition.

In registration acceptance, once the disaster condition applies, the NW may inform the WTRU of the list or scope of PLMNs that the WTRU may attempt to register on. The list may be provided/sent/delivered in a priority order. Information may also be received via the WCU procedure after registration.

Based on the type and/or capabilities of the WTRU (e.g., common or smart phone and cellular internet of things (CIoT) device), the NW may provide one or more different PLMN lists and other registration information, such as nsais (e.g., different nsais for different types of WTRUs).

For never going toRepresentative procedure for providing indication of accessibility to a WTRU by other PLMNs with catastrophic conditions

When the WTRU selects a target PLMN, an indication of support may be broadcast by the RAN in the target PLMN. For example, the RAN of a PLMN not associated with the disaster condition may indicate to the WTRU the RAN and/or the accessibility of the PLMN via, for example, a broadcast message and/or system information.

When the WTRU registers with the new PLMN, the WTRU may provide an indication that the registration of the inbound roamer is due to a "disaster condition" along with any of a globally unique AMF ID (guimi), a serving temporary mobile subscriber identity (S-TMSI), and/or an nsai. Using this information, the RAN may select a particular AMF (e.g., a special AMF) that the operator has specified. To extend inbound roamers (e.g., IDR WTRUs), the RAN node may be configured by an operator to select different AMF entities. The determination/selection of a particular AMF entity may be based on the geographic region of the IDR WTRU and/or one or more priority orders of the AMF/IDR WTRU.

The WTRU may indicate to the new AMF that the WTRU is an inbound roamer due to a "disaster" (e.g., the inbound roamer is an IDR WTRU). The AMF may run authentication (e.g., trigger an authentication procedure), however, this type of WTRU (e.g., IDR WTRU) may be automatically authorized to stay there. For example, the AMF may allow/authorize the WTRU to obtain service herein based on the WTRU being an inbound disaster roamer WTRU even if authentication fails.

Upon or after registration of the IDR WTRU, the IDR WTRU may be provided with signed credentials over a secure channel (e.g., NAS) for acceptance at the "other PLMN". The credential may include or comprise any of the following: for example, (1) WTRU identity, (2) PLMN identity, (3) maximum duration of service for "other PLMNs", and/or (4) future payable service for the original PLMN, etc. The WTRU may send/forward credentials instead of SUPI if: (1) Upon registration with the "other PLMN" and/or (2) after the initial registration is denied and the roaming NW solves the problem using a predetermined "disaster recovery" protocol with the disaster affected PLMN or by looking at the data in the credentials. It is contemplated that for the latest notification of "other PLMNs," a new interface between "disaster recovery" entities in the PLMNs (e.g., any PLMN) may be used/may be required.

In the event that authentication is not possible, for example, because the new PLMN is unable to obtain an authentication vector from the HPLMN of the WTRU (e.g., because the UDM is not reachable), any of the following procedures may be implemented, including:

(1) Upon or after receiving the registration request, the new NW/PLMN may send a message to the WTRU indicating that the NW cannot obtain an authentication vector for the WTRU (e.g., by defining a new cause code in a registration reject message sent by the NW to the WTRU). The WTRU may provide the credentials/tokens the WTRU has received from the HPLMN in a new registration accept message. The receipt of the "credential/token" may imply/indicate that the WTRU is authorized to register in the new NW; and/or

(2) The WTRU may be configured with one or more algorithms by the HPLMN that the WTRU may use in case of registration in another PLMN, e.g., after a disaster condition is applicable in the HPLMN. For example, the HPLMN may have agreed with certain operators of the country and may have informed the operators of one or more algorithms. During registration, the HPLMN may provide one or several of these algorithms to the WTRU (e.g., the NW may send an indication of the correct algorithm (e.g., algorithm number/algorithm identification along with a random string.) when the WTRU starts to register in the new PLMN, the WTRU may provide the permanent ID of the WTRU (IMSI/SUPI), the indication (e.g., algorithm number) and the random string.

Representative procedures for inbound rover registration in PLMN (e.g., no roaming with disaster in HPLMN) Authorized disaster conditions

The DRF may be deployed in a PLMN (e.g., PLMN D) (with a disaster condition), another PLMN (e.g., PLMN a) (e.g., which is active, accepting inbound roamers from PLMN D), and in the HPLMN of the WTRU.

Upon registration with PLMN D, the WTRU may receive a disaster response configuration parameter including a "temporary" unique disaster response event ID (DRID) and/or a list of PLMNs authorized to accept inbound roamers from PLMN D. When the WTRU is notified of the disaster condition in PLMN D, the WTRU may select another PLMN a based on the embodiments described herein. The WTRU registers with PLMN a indicating that the registration is for disaster inbound roaming. The WTRU includes in the registration request message disaster response parameters that may include: DRID and/or ID of PLMN D. If the registration is successful, the WTRU may receive parameters related to the disaster response from PLMN a (e.g., mobility restriction parameters when PLMN a is used, and/or a timer (e.g., value and/or timeout period, etc.) for re-registering with PLMN D, e.g., when the disaster condition ends).

When PLMN D determines that a disaster condition exists (e.g., a disaster condition is encountered), for example, if PLMN D is different from the HPLMN, the DRF associated with PLMN D may notify one or more DRFs associated with (e.g., used by) PLMN a and/or HPLMN of the disaster condition including DRID. If PLMN D is different from the HPLMN, the DRF of the HPLMN may provide a list of one or more PLMNs authorized for disaster inbound roamers by PLMN D. It is contemplated that disaster information for the DRF associated with PLMN D may be obtained from the MNO's Network Management System (NMS) or any other system with disaster detection capability. The DRF may be a service provided by the UDM.

Fig. 4 is a diagram illustrating a registration process 400 with a roaming PLMN without a disaster condition in the event of a disaster condition (e.g., the roaming PLMN is not an HPLMN, the roaming PLMN does not have a current disaster condition, and the roaming PLMN may have determined that another PLMN has a disaster condition associated with the other PLMN).

Referring to fig. 4, the registration process 400 may include any of the following operations:

(1) At operations 4-0a and 4-0b, the WTRU 102 may be configured with DRID (e.g., unique temporary DRID) when the WTRU 102 registers with PLMN D. The configuration information may be received during registration (e.g., using a registration accept message) or during a WTRU configuration update procedure. The WTRU 102 may receive other disaster response parameters, such as a list of authorized PLMNs for inbound roaming (e.g., when a disaster condition occurs, the DRF of PLMN D may notify the DRF of PLMN a about the disaster (e.g., disaster condition), and may provide DRID and/or other disaster condition information (e.g., such as one or more affected areas)), the DRF of PLMN D may notify the HPLMN of the list of authorized PLMNs for inbound roaming (e.g., PLMN a, etc.), when the WTRU detects a disaster condition, may notify the WTRU that PLMN a is accepting an inbound roamer based on the ID of PLMN a and the DRID, e.g., the broadcast PLMN ID of PLMN a may be part of a list of PLMNs authorized to provide inbound roaming services, the DRID broadcast by PLMN a may be broadcast by selected cells of PLMN a in order to limit inbound DRID access to those cells (e.g., used in the access control mechanism), may be based on the ID of PLMN a and DRID may be random, e.g., may be included in the WTRU may be configured to be a small cell, may be a WTRU may be a random, may be included in the WTRU may be configured to be a small cell, and may be a random cell may be included if the WTRU is a random cell D is a cell is

+mobile network code (MNC)). The WTRU may select PLMN a based on the configured list of PLMNs authorized for inbound roaming;

(2) At operation 4-1, the WTRU 102 may send a registration request message indicating that this is a subscription hide identification (sui) for the disaster inbound roaming registration and may include the WTRU 102's subscription hide identification (DRID) and/or PLMM ID (e.g., MCC and MNC) of the PLMN D (e.g., the WTRU 102 may transmit a hide DRID calculated and/or generated using the common key of the HPLMN 420, the same protection scheme and/or method used to hide the subscription permanent identification (SUSI) into the sui. The WTRU 102 may omit DRID in the request message. When the request message is transmitted from the WTRU 102 to the AMF 182, the NG-RAN may provide (e.g., by the cell) the supported DRID to the AMF 182;

(3) At operation 4-2, the AMF 182 may send an authentication request to an authentication server function 430 (AUSF) in the HPLMN 420 and may forward the parameters from operation 4-1 along with the PLMN ID of PLMN a 410;

(4) At operation 4-3, AUSF 430 may send an authentication request including the above to UDM 440;

(5) At operation 4-4, UDM 440 may perform the unhidding of the sui into the SUPI using a subscription identification unhidding function (SIDF) and using the HPLMN private key in accordance with existing unhidding procedures (e.g., if the received DRID is hidden, UDM/SIDF 440 may perform the unhidding of the hidden DRID using the same procedure);

(6) At operations 4-5, the UDM 440 may send a request to the DRF including the DRID and the ID of the PLMN (e.g., PLMN a, PLMN D); the UDM 440 may omit DRID not provided by the WTRU 102;

(7) At operations 4-6, the DRF 450 may retrieve disaster response information identified by the DRID and/or PLMN ID or PLMN D and may verify that the PLMN (e.g., PLMN a) is part of the list of authorized PLMNs for inbound roaming;

(8) At operations 4-7, the DRF 450 may send a response to the UDM 440, the result of which (e.g., success/failure) indicates whether the WTRU 102 is authorized to perform inbound roaming in the PLMN (e.g., PLMN a) from another PLMN (e.g., PLMN D). The DRF 450 may include a list of applicable/allowed DRIDs for PLMN D in the response message;

(9) At operations 4-8, if the DRF 450 sent a success result, the UDM 440 may send an authentication vector and SUPI to the AUSF 430 in accordance with existing authentication procedures (and, for example, the UDM 440 may otherwise reject the authentication request);

(10) At operations 4-9 to 4-18, if UDM/DRF verification is successful, the authentication procedure of the WTRU 102 may be performed between or among the WTRU 102, AMF 182 and/or AUSF 430 in accordance with existing authentication procedures (e.g., the AUSF 430 may provide SUPI to the AMF 182 and, if applicable, the unhidden DRID). The UDM 440 may send a response hereinafter, thereby illustrating a 5G AKA authentication procedure (alternatively, EAP-AKA procedure may be used).

(11) At operations 4-9, AUSF 430 may temporarily store the expected response (XRES) with the received sui or SUPI;

(12) At operations 4-10, AUSF 430 may generate an Authentication Vector (AV) (e.g., 5G AV) from a Home Environment (HE) AV (e.g., 5G HE AV) received from a UDM/authentication credential repository and processing function (ARPF) by: calculate/determine HXRES from XRES and from K _AUSF Calculation/determination of K _SEAF And replace XRES with HXRES and K _AUSF Replaced by K in 5G HE AV _SEAF ；

(13) At operations 4-11, AUSF 430 may remove K that returns a Service Environment (SE) AV (e.g., 5G SE AV) (based on RAND, authentication token (AUTN), and/or HXRES) to AMF/SEAF 182 in a nausf_ueauthentication_authentication response _SEAF ；

(14) At operations 4-12, the AMF/SEAF 182 may send the RAND and/or AUTN to the WTRU 102 in a NAS message authentication request (e.g., the message may include information that may be used by the WTRU 102 and/or the AMF 182 to identify K _AMF And a partial local security context that can be created in case of successful authentication. The message may include an Anti-fabric gap price (Anti-Bidding down Between Architecture) (ABBA) parameter. AMF/SEAF 182 may set the ABBA parameters. The WTRU/Mobile Equipment (ME) may forward the RAND and AUTN received in the NAS message authentication request to a UMTS Subscriber Identity Module (USIM). ABBA parameters may be included to enable pressed price protection);

(15) At operations 4-13, upon receipt of the RAND and AUTN, the USIM may verify the freshness of the 5G AV, e.g., by checking if the AUTN is acceptable (e.g., if it is acceptable, the USIM may determine/calculate the response RES. The USIM may return RES, the first key (e.g., CK) and/or the second key (e.g., IK) to the ME. If the USIM uses transfer function c3 to calculate/determine Kc (e.g., GPRS Kc) from the first key (e.g., CK) and the second key (e.g., IK), and send it to the ME, the ME may ignore GPRS Kc and not store GPRS Kc on or in the USIM, the ME may calculate/determine RES from RES. The ME may calculate/determine K from ck|ik) _AUSF . ME can be obtained from K _AUSF Calculation of K _SEAF . The ME accessing 5G may check during authentication that the "detach bit" in the AMF field of the AUTN is set to 1. The "split bit" is 0 bit of the AMF field of AUTN. For example, AMF words of AUTNThe split bits in the segment may no longer be used for operator specific purposes);

(16) At operations 4-14, the WTRU 102 may return RES to AMF/SEAF in a NAS message authentication response.

(17) At operations 4-15, AMF/SEAF 182 may calculate/determine HRES from RES and AMF/SEAF 182 may compare HRES and HXRES (e.g., if HRES and HXRES agree, AMF/SEAF may determine/consider authentication success from the service network perspective;

(18) At operations 4-16, the AMF/SEAF 182 may send RES as received from the WTRU 102 to the AUSF 430 in a ausf_ue authentication_authentication request message;

(19) At operations 4-17, when ausf_ueauthentication_authentication request message including RES is received by AUSF 430 as authentication acknowledgement, AUSF 430 may verify whether AV has timed out (e.g., if AV has timed out, AUSF 430 may consider/determine authentication unsuccessful from the home network perspective, AUSF 430 may store K upon successful authentication) _AUSF . AUSF 430 may compare/match the received RES with the stored XRES. If RES and XRES are equal, AUSF 430 may consider/determine authentication success from the home network perspective. The AUSF 430 may inform the UDM 440 about the authentication result (e.g., to associate with an authentication confirmation).

(20) At operations 4-18, the AUSF 430 may indicate to the AMF/SEAF 182 in a nausf_ueauthentication_authentication response whether the authentication was successful from the home network perspective (e.g., if the authentication was successful, K) _SEAF May be sent to the AMF/SEAF 182 in a nausf_ueauthentication_authentication response. In the event that the aucf 182 receives the sui from the AMF/SEAF 182 in the authentication request, and if authentication is successful, the aucf 430 may include the sui in a nausf_ueauthentication_authentication response message. If authentication is successful, the key K received in the Nausf_UEAuthentication_Authenticate response message _SEAF Can become an anchorA key is fixed (e.g., in the sense of a key hierarchy). AMF/SEAF 182 is available from K _SEAF ABBA parameters and/or SUPI derived K _AMF . AMF/SEAF 182 can convert ngKSI and K _AMF Is provided to AMF 182. If SUCI is used for the authentication, AMF/SEAF 182 may provide (e.g., may only provide) ngKSI and K to AMF 182 after AMF 182 has received a Nausf_UEauthentication_authentication_authentication response message containing/including SUPI _AMF . In some embodiments, no communication services may be provided to the WTRU 102 until the serving network is aware of the SUPI);

(21) At operations 4-19, upon or after successful registration, WTRU 102 may receive disaster response parameters to be used upon registration with PLMN a, and when the disaster conditions end as described herein, AMF/SEAF 182 may retrieve disaster response information from the DRF (such as the disaster-affected area) (e.g., locally and/or in the HPLMN/via UDM) to derive disaster response parameters (e.g., mobility restrictions upon inbound roaming). In other representative embodiments, after successful authentication of the WTRU 102 (e.g., if the AMF 182 does not receive DRID from the WTRU 102 and/or AUSF 430 during authentication), the AMF 182 may request a list of allowed/applicable DRID for PLMN a/PLMN D from the UDM 440/DRF 450. In this case, AMF 182 may send a request to UDM 440 to provide the SUPI, PLMN D/PLMN a PLMN ID. The UDM 440 may request the DRF 450, as described above, and may send a list of allowed/applicable DRIDs to the AMF 182 in a response message. The AMF 182 may compare DRID supported by NG-RAN as received with the initial message from WTRU 102 (e.g., as shown above) with allowed/applicable DRID received from UDM 440/DRF 450. The AMF 182 may accept the WTRU registration request if one or more of the DRIDs supported by the NG-RAN are part of the allowed/applicable DRIDs. The AMF 182 may reject the WTRU request to provide a reason indicating that disaster inbound roaming is not authorized.

For enhancing DRID-based implementations to support registration with PLMN (e.g., PLLMD) or in disaster recovery Representative procedure for disaster roaming for WTRUs in the vicinity of a loud region

In some embodiments, the WTRU may not have registered with PLMN D (with or having a disaster condition) or be near a disaster affected area. For example, the WTRU may not have registered with the PLMN (e.g., PLMN D with a disaster condition) when the WTRU is powered up in the disaster affected area, or registration of the WTRU with the PLMN (e.g., PLMN D) has not been successfully completed (e.g., due to a disaster condition failure).

A representative procedure for a WTRU may use one or more regional level DRIDs from a PLMN (e.g., PLMND) For disaster roaming registration in another PLMN (e.g., PLMNA)

Upon registering with PLMN D (a PLMN that will have a disaster condition, e.g., before/before the disaster condition), the WTRU may receive one or more allowed regional level DRIDs. The DRID may consist of or may include the following: PLMN identification (PLMN ID) (e.g., mobile Country Code (MCC) +mobile network operator (MNC) (mcc+mnc)), area Identification (AID), and/or Disaster Recovery Code (DRC). DRID may be a concatenation of PLNM ID, AID, and DRC (e.g., drid=plmn id+aid+drc) or may be derived from PLMN ID, AID, and DRC. The AID may identify a geographic area mapped to a portion of the RAN coverage area of PLMN D (e.g., NG-RAN coverage area of NR-RAN PLMN D, such as one or more NG-RAN nodes, and/or one or more Tracking Areas (TAs)). The WTRU may be informed by PLMN D to perform a PLMN search using one or more DRIDs (e.g., during a handover or based on a mobility mode while the WTRU is moving towards a known disaster affected area). The WTRU may receive an explicit indication from the AMF of PLMN D to begin cell search with and/or using the one or more DRIDs. The WTRU may select PLMN a based on: a matching DRID, or a portion of a DRID that matches (e.g., DRC) broadcast by PLMN a with one or more allowed DRIDs. The WTRU may register with PLMN a for inbound roaming, which provides a matching protected DRID to be authorized for inbound roaming by the HPLMN, as described herein.

Representative procedures for a WTRU may use regional and/or PLMN level DRID from the HPLMN for PLMNs Disaster roaming registration in A

The WTRU may be configured (by the HPLMN) with one or more allowed regional level DRIDs and/or allowed PLMN level DRIDs associated with a given PLMN (e.g., PLMN D, HPLMN as WTRU). PLMN-level DRIDs may have a composition similar to region-specific DRIDs, except that the AID may identify geographic regions mapped into the entire PLMN. The regional DRID may have a composition similar to the regional specific DRID, except that the AID may identify a geographic region that maps a portion (e.g., a broad area) of coverage (e.g., city, state, and/or province) of the PLMN. The WTRU may select PLMN a with allowed regional or PLMN level DRID based on a match (e.g., a match with mcc+drc) with the DRID or a portion of the DRID broadcast by PLMN a. The WTRU may register with PLMN a for inbound roaming, which provides a protected regional or PLMN level DRID to be authorized for inbound roaming by the HPLMN, as described herein.

Representative network side behavior

Fig. 5 is a diagram illustrating a representative process for disaster roaming using one or more DRIDs.

Referring to FIG. 5, multiple PLMNs (e.g., a first PLMN 205D that may experience a disaster condition and a second PLMN 205A that may not experience a disaster condition) may have overlapping Tracking Areas (TAs), cells, and/or gNBs 180. For example, the first PLMN 205D may include a first gNB 180-D1 with a first corresponding TA (e.g., TA-D1), a second gNB 180-D2 with a second corresponding TA (e.g., TA-D2), and a third gNB 180-D3 with a third corresponding TA (e.g., TA-D3). The second PLMN 205A may include a fourth gNB 180-A1 with a fourth corresponding TA (e.g., ta-A1) and a fifth gNB 180-A2 with a fifth corresponding TA (e.g., ta-A2). The TA of the first PLMN 205D may be offset from the second PLMN 205A, and/or may have a larger or smaller coverage area/TA., e.g., and the fourth gNB 180-D1 and the fourth gNB 180-A1 may be associated with the second gNB 180-A2 and the fifth gNB 180-A2 may partially overlap with the first and second gNB 180-A2 and the fifth gNB 1 and the fifth gNB 2 may be associated with the second gNB 180-A2.

Control/broadcast signaling for the first PLMN 205D may be provided by the D-AMF 182D to the first, second and/or third gnbs 180-D1, 180-D2 and/or 180-D3. Control/broadcast signaling for the second PLMN 205A may be provided by the A-AMF 182A to the fourth and/or fifth gnbs 180-A1 and/or 180-A2.

The WTRU1 102-1 may be located in multiple coverage areas/TAs associated with the first PLMN 205D and the second PLMN 205A. For example, the WTRU 102-1 may be located in the first TA TA-D1 and in the fourth TA Ta-A1 for possible communication via the first gNB 180-D1 and/or the fourth gNB 180-A1. The WTRU1 102-1 may be configured from the first PLMN 205D.

The fourth gNB-A1 may provide disaster roaming services in areas D1 and D2 of the PLMN 205D and may broadcast DRID or a portion of DRID for these areas (e.g., by broadcasting codes such as a first code (e.g., code 1) and a second code (e.g., code 2)). The fifth gNB 180-A2 may provide disaster roaming services in an area D2 (e.g., only area D2) of the PLMN 205D and may broadcast (e.g., a second code (e.g., only second code (e.g., code 2)) for the area.

The WTRU1 102-1 may be configured with any one of the following: (1) A TAI list comprising, for example, information indicating TA-D1 and/or TA-D2, and/or (2) a DRID list comprising, for example, information indicating DRID1 and/or DRID 2. The WTRU1 102-1 may detect that the second PLMN 205A provides disaster roaming services by: DRID1 or DRID2 (e.g., code 1 or code 2) broadcast via the gNB 180-A1 and/or 180-A2 of PLMN 205A is matched to DRID from the configured DRID list.

As another example, the second WTRU 2-2 may be located in a coverage area/TA associated with the first PLMN 205D. For example, the second WTRU 102-2 may be in a third TA (e.g., TA-D3) to communicate via a third gNB (e.g., 180-D3). The second WTRU 2-2 may be configured from the first PLMN 205D. The second WTRU 102-2 may be outside of the disaster area/zone and may be configured with any of the following: (1) A TAI list comprising, for example, information indicating TA-D2 and/or TA-D3, and/or (2) a DRID list comprising, for example, information indicating DRID1 and/or DRID 2. The second WTRU 2-2, when moving towards a disaster area/zone (e.g., TA-D2), may detect that the second PLMN 205A provides disaster roaming services by: DRID2 (e.g., code 2) broadcast via the gNB 180-A1 and/or 180-A2 of PLMN 205A is matched to DRID from the configured DRID list.

In certain representative embodiments, the DRID information may include a combination of any of the following: (1) an identification of PLMN 205, (2) area information (e.g., area 1 and/or area 2), and/or (3) code information (e.g., a code such as code 1). For example, DRID1 may be a combination of: (1) an identification of the first PLMN 205D, (2) a region identification (e.g., region 1), and (3) a code (e.g., code 1). As a second example, DRID2 may be a combination of: an identity of the first PLMN 205D, a region identity (e.g., region 2), and a code (e.g., code 2). Region 1 may be mapped to a first gNB 108-D1 and region 2 may be mapped to second and third gNB 180-D2 and 180-D3.

For example, before a disaster condition occurs, such as when WTRU1 102-1 registers with PLMN D205D, AMF 182D may provide one or more allowed DRIDs to WTRU 102-1 (e.g., may provide information indicating the one or more allowed DRIDs) based on any of the following: (1) a mobility mode of the WTRU 102, (2) an allocated TAI list, or (3) a size of an area tracked by the DRID, etc., and may register the one or more allowed DRIDs with the UDM 440/DRF 450. The AMF 182D may update the WTRU 102 and/or UDM 440/DRF 450 with information indicating the one or more allowed DRIDs based on WTRU mobility. The area identified by the DRID is contemplated to be large enough (e.g., to cover one or more tracking areas) to avoid frequent updates of the DRID by the AMF 182D.

When a disaster condition occurs, PLMN D205D (e.g., UDM 440/DRF 450 associated with PLMN D205D) may provide information (e.g., regional DRID (e.g., regional specific DRID)/regional DRID/PLMN level DRID or a portion of DRID) (such as DRC) and/or geographic coordinates) about the affected area to PLMN a 205A (e.g., UDM/DRF associated with PLMN a 205A). PLMN a 205A may indicate to PLMN a 205A that PLMN D may be provided with disaster roaming services by broadcasting any applicable DRID (e.g., regional/PLMN level DRID). The AMF 182A in or associated with PLMN a 205A may obtain disaster information from the DRF of PLMN a 205A (e.g., in the form of one or more mapped tracking areas in PLMN a 205A) and may thus configure supported DRIDs for one or more applicable RAN nodes. PLMN D205D may provide information about the affected area (e.g., area-level DRID (e.g., area-specific DRID)/regional-level DRID/PLMN-level DRID or a portion of DRID) to the HPLMN.

When the WTRU 102 registers with PLMN a 205A for disaster roaming, the AMF 182A may forward the DRID received from the WTRU 102 to the HPLMN, as described herein. The AMF 182A may provide (e.g., additionally provide) the supported regional level DRID or a portion thereof (e.g., DRC) in accordance with the RAN node configuration described above. This information may be used to assist the UDM/DRF in identifying the current zone level DRID if or when it is not available from the WTRU 102. The UDM/DRF may authorize the WTRU 102 authentication to proceed in PLMN a 205A based on any of the following: (1) one or more received DRIDs, (2) previous registration information from PLMN D205D (e.g., allowed DRID for WTRU 102), (3) applicable disaster condition information obtained from PLMN D205D (e.g., disaster affected DRID), and/or (4) supported DRID/DRC from PLMN a 205A. For example, if the WTRU 102 has not previously registered for the WTRU 102 in PLMN D205D, the UDM/DRF may authorize WTRU authentication in the case where the WTRU 102 provides regional or PLMN level DRID and there are one or more disaster-affected areas for the area or PLMN. The UDM/DRF may use the supported DRID information from the PLMN a 205A to determine and update a current regional level (e.g., regional specific DRID)/regional level DRID, where the WTRU 102 is registering from the PLMN a 205A (e.g., the DRF may match the received DRC with the corresponding affected DRID). The AMF 182A in PLMN a 205A may update the UDM/DRF with the current regional/regional DRID (or a portion thereof, e.g., DRC) as the WTRU 102 moves across the disaster area under PLMN a coverage.

Representative procedure to determine the last location of the WTRU in the PLMN (e.g., PLMN D) with a disaster (e.g., with a disaster condition).

In some examples, the HPLMN (PLMN D) may match (e.g., easily match) the location of the WTRU based on: the location where the WTRU is located in PLMN a (e.g., is now in PLMN a), and the last known Tracking Area (TA) where the WTRU is registered in PLMN D. The WTRU may receive the list of TAs when the WTRU registers with the network and may perform (e.g., perform only) mobility registration updates when the WTRU enters a cell belonging to a TA that is not in the TA list. For example, it is contemplated that when/by the WTRU is registered in/by the AMF of PLMN D, the WTRU is in a first TA (e.g., TA 1), and the AMF may send a TA list including or consisting of information indicating TA1, TA2, and TA 3. Thus, the WTRU may not have performed a mobility registration update as long as the TA is in any of the three TAs (e.g., TA1, TA2, or TA 3). Using/based on or with the regional granularity of the TA may be sufficient (e.g., considered sufficient) for PLMN a and PLMN D to verify whether the particular WTRU is actually in the disaster area at the time of the disaster. The AMF of PLMN D may not be needed/used to "exactly" know in which TA the WTRU resides before the disaster occurs. In some representative embodiments, a more specific location of the WTRU may be determined by any one of the following:

(1) During the registration procedure, the WTRU and the AMF of PLMN D may negotiate the use of NAS messages (e.g., special NAS messages) to be communicated when the WTRU changes the TA indicated in the TA list (this may be done by the WTRU sending information in the registration request message indicating one or more WTRU MINT capabilities and the AMF informing the WTRU that the WTRU is allowed and/or configured to send special NAS messages when the WTRU crosses a boundary between or among TAs indicated in the TA list;

(2) As an alternative to sending a service request message, the WTRU may use a new NAS message that does not include/contain any valuable information other than the identity of the WTRU (e.g., 5G-GUTI of the WTRU) (e.g., the use of a special NAS message may be limited to only a mit-capable WTRU-on the NW side, the receipt of this special NAS message may change the mobility management context of the WTRU so that the last registered TA may become the TA in which the WTRU resides when sending the message);

(3) A MINT-capable WTRU may perform mobility registration update upon entering a new TA, even if the new TA belongs to or is associated with a TA list; and/or

(4) When the AMF of PLMN D determines/recognizes that the WTRU is capable of MINT, the AMF may not allocate a TA list to the WTRU and may provide (e.g., only provide) one TA in the registration accept message.

Additional representative procedures for informing disaster conditions no longer applicable to a WTRU

In some representative embodiments, notification that a disaster condition no longer exists or is no longer applicable may not be critical, and it is contemplated that the NW may notify/inform the WTRU when (e.g., only) the WTRU is in "connected mode". In other representative embodiments, such notification may occur in a connected mode and/or an RRC inactive mode. For example, the NW may send a Configuration Update Command (CUC) message to the WTRU as part of the WCU procedure while the WTRU is in connected mode, or may page the WTRU to put the WTRU into connected mode and may then begin the WCU procedure. In both cases, the NW may force the WTRU to perform a registration procedure (e.g., a conventional procedure). When the WTRU triggers the registration procedure, the NW may reject the registration request message with a cause value (e.g., a special cause value) that may direct the WTRU to the HPLMN.

Additional representative procedure for preventing signaling overload in PLMNs without catastrophic conditions

When the WTRU registers with the HPLMN, the AMF may provide a timer (e.g., a timer value) to the WTRU in a registration accept message. The WTRU may use the timer value in conjunction with certain parameters of the WTRU and/or local parameters (such as SUPI and/or permanent device identification) to derive a "time window" through which the WTRU may perform registration with the new PLMN. The RAN may provide information by the CN to prevent/defer RRC connection from an inbound WTRU (e.g., an IDR WTRU). The WTRU may use a new specific establishment cause (e.g., "inbound WTRU request due to disaster") when sending the RRC connection request. The RAN may provide a new timer in the RRC connection reject message that may push/change the timing of the attempt at the WTRU to NW connection/reconnection to a different time (e.g., slightly later). To further randomize the timing for connection/reconnection to the NW, the WTRU may use a formula based on the timer value and the WTRU's own ID.

Additional representatives for preventing signaling overload by returning the WTRU to the previous disaster-conditioned PLMN Sexual procedure

Figure 6 is a diagram illustrating a representative process for determining when to perform registration with the HPLMN after a disaster (e.g., disaster condition).

Referring to fig. 6, a representative process 600 may include: at operation 6-1, a Network Entity (NE)/AMF 182 associated with the Home PLMN (HPLMN) 620 determines parameters of the WTRU 102 to return (e.g., to return to) the HPLMN 620 serving the WTRU 102 before the disaster situation/condition has occurred. At operation 6-2, NE/AMF 182 of HPLMN 620 may send a message (e.g., a registration accept message) that may include information indicating, for example, a time value and a priority value. At operation 6-3, the WTRU 102 may determine that the disaster condition/situation has ended. At operation 6-4, the WTRU 102 may determine the registration time based on any one of the following: (1) WTRU ID, (2) received time value, and/or (3) received priority value. At operation 6-5, the WTRU 102 may perform registration with the HPLMN 620 at or after the determined registration time. At operation 6-6, the WTRU 102 may send a registration request to the NE/AMF 182 of the HPLMN 620, the registration request including information indicating a priority value in a message (e.g., an RRC message).

For example, the HPLMN 620 may provide the timer value to the WTRU 102 at registration. This timer (e.g., a timer value) along with other WTRU-specific parameters such as WTRU-ID may be used to determine when the WTRU 102 may start registration, when the WTRU 102 may return (e.g., may return to the HPLMN 620). The HPLMN 620 may provide the WTRU 102 with a "priority/priority value" at registration. The WTRU 102 may input a priority/precedence value into the algorithm to determine the time to register back with the HPLMN 620 that had an applicable disaster condition after moving to a PLMN that did not have an applicable disaster condition (e.g., moving back from another PLMN to a PLMN that had an applicable disaster condition). WTRU 102 may provide a priority value to RAN 610 in RRC signaling. RAN 610 may have been configured for this by the CN and may prioritize the registration requests of the WTRUs, e.g., based on a priority value.

Additional representative procedures for outbound roam WTRUs

The WTRU may roam in any number of geographical areas/countries (e.g., in another country), and disaster conditions may occur in the HPLMN of the WTRU. The serving NW (e.g., in other geographic areas and/or countries) may not be able to re-authenticate the WTRU when transitioning to connected mode. To address this issue, the WTRU may be configured with tokens/credentials (e.g., special tokens/credentials) for roaming scenarios by the HPLMN. When the WTRU registers with a new (e.g., roaming) PLMN, the HPLMN may provide tokens/credentials to the serving PLMN. Thereafter, when the WTRU transitions to connected mode and the serving PLMN performs re-authentication of the WTRU without any further authentication vectors, the NW may send a message using the secure communication that has been established between the WTRU and the CN to inform the WTRU that the NW cannot retrieve the authentication vectors due to, for example, impossibility of communication with the HPLMN. The serving NW may force/cause the WTRU to re-register. Upon re-registration, the WTRU may provide the corresponding credentials/tokens in the registration request message.

Fig. 7 is a diagram showing a representative registration process.

Referring to fig. 7, a representative registration process 700 may include: at operation 7-1, the WTRU 102 sends a registration request to the HPLMN 205H (e.g., a Network Entity (NE) and/or AMF 182H) that includes information indicating WTRU capabilities (e.g., MINT capabilities). At operation 7-2, the NE/AMF 182H may determine to assign one or more time values (e.g., timers) to the WTRU 102. At operation 7-3, NE/AMF 182H may send a registration accept to WTRU 102 that includes a first time value for disaster roaming and/or a second time value for return to HPLMN 205H. At operation 7-4, the WTRU 102 may use either the first time value and/or the second time value in conjunction with the unique identification of the WTRU 102 to derive start and/or stop times associated with one or more time windows. The WTRU 102 may determine that the start of the first window has occurred, e.g., at operation 7-6, to trigger the WTRU 102 to send a second registration request to a second PLMN (e.g., NE/AMF 182F of the FPLMN 205F).

Fig. 8 is a flow chart illustrating a representative method implemented by a WTRU.

Referring to fig. 8, a representative method 800 may include: at block 810, the WTRU 102 receives information from the first network 205D indicating a value to be used during registration with the second network 205A. At block 820, the WTRU 102 may determine at least a first start time and a second start time from which to perform registration with the second network 205A based at least on the indicated value. At block 830, the WTRU 102 may initiate registration with the second network 205A after the first start time. At block 840, the WTRU 102 may, on condition that registration is not completed within a defined period after the first start time: (1) The registration with the second network 205A is aborted, and (2) a second registration or re-registration of the WTRU 102 with the second network 205A is initiated after a second start time.

In some representative embodiments, the received information indicative of the value may also be indicative of a time window, and/or the defined period may be based on a duration of the time window.

In some representative embodiments, the WTRU 102 may determine the time window based on one of (1) the first start time and (2) the following: the duration of the end time or first time window is based on: (i) the indicated value and any one of the following: (ii) a random value; or one or more parameters specific to WTRU 102.

In some representative embodiments, the received information may indicate an identity of the WTRU 102.

In some representative embodiments, the WTRU 102 may be a disaster rover. In some examples, the received information may indicate a second value that is used to determine when to allow the WTRU 102 to access the first network 205D or another network to which the WTRU 102 is registered before the first network 205D or another network experiences a disaster condition.

In some representative embodiments, the WTRU 102 may send and/or receive data transmissions via the second network 205A under the condition that registration is completed during a defined or predetermined period.

In some representative embodiments, the WTRU 102 may send and/or may receive data transmissions via the second network 205A under the following conditions: (1) Registration is completed during a defined period, or (2) a second registration or re-registration is completed after a second start time.

In some representative embodiments, the WTRU 102 may determine that registration is incomplete based on any one of the following: (1) A registration reject message is received from network entity 182A that includes information indicating that registration is rejected, or (2) no registration accept message is received within a defined period.

In some representative embodiments, the WTRU 102 may receive information indicating: (1) The disaster condition applies to the first network 205D, and (2) a second value to be used in determining when to allow the WTRU 102 to register or re-register with the first network 205D after the disaster condition is no longer applicable to the first network 205D.

In some representative embodiments, the initiation of registration may include the WTRU sending a registration request message to the network entity 182A of the second network 205A serving the WTRU 102, the registration request message including information indicating any one of: (1) Event identification, (2) identification of the first network 205D, any of the following: (i) a location associated with the WTRU 102; (ii) a disaster or coverage area associated with the WTRU 102; (iii) One or more tracking areas associated with the WTRU 102; and/or (iv) the last visited tracking area of WTRU 102.

In some representative embodiments, the WTRU 102 may perform any one of the following operations under the condition that the WTRU supports a service interruption minimization (mit) operation: (1) Determining whether the WTRU 102 has changed coverage area from a first TA associated with a received Tracking Area (TA) list to a second TA associated with the received TA list; (2) Transmitting a non-access stratum message to the network entity 182A of the first network 205A, the non-access stratum message indicating that the WTRU 102 has changed coverage area from a first TA associated with a received Tracking Area (TA) list to a second TA associated with the received TA list; (3) Receiving an indication to re-register with the second network 205D with which the WTRU 102 was previously registered; and/or (4) re-register with the second network 205D via the WTRU 102.

In some representative embodiments, the WTRU 102 may perform any one of the following operations: (1) Transmitting information indicative of a disaster roaming indication during the disaster condition (e.g., paging/broadcasting of a warning of the disaster condition); and/or (2) receive a message to initiate authentication of the WTRU 102 based at least on the disaster roaming indication.

In some representative embodiments, the receiving of the information indicative of the value to be used during registration with the second network 205A includes the WTRU receiving configuration information from the first network entity 182D associated with the first network 205D, the configuration information indicating one or more disaster response event identifications (DRIDs) associated with the disaster response. For example, the WTRU 102 may receive broadcast information from the second network entity 182A of the second network 205A indicating one or more allowed DRIDs or portions thereof. The WTRU 102 may select a DRID of the indicated DRIDs that matches the one or more allowed DRIDs or portions thereof and may send a registration request message to the second network entity 182A, the registration request message including information indicating the selected DRID or a portion of the selected DRID. The WTRU 102 may receive a registration accept message from the second network entity 182A on condition that the WTRU 102 is within a portion of the second network 205A.

In some representative embodiments, the selected DRID may include an Area Identification (AID) corresponding to a disaster response service area as part of the second network 205A, which AID may be used for registration during disaster conditions associated with the first network 205D. In some examples, the WTRU 102 may be within a disaster-response service area of the second network 205A when the WTRU 102 is any of the following: (1) Within one or more particular tracking areas of the second network 205A; (2) Within one or more particular cells of the second network 205A; (3) In proximity to one or more particular RAN nodes of the second network 205A; (4) being within a particular coverage area of the second network 205A; (5) being within the entire coverage area of the second network 205A; and/or (6) in the vicinity of any RAN node of the second network 205A.

In certain representative embodiments, each DRID can include a Disaster Recovery Code (DRC) such that selection of a DRID of the indicated DRIDs is based on a match of one of the DRCs of the indicated DRIDs with the DRCs of one of the one or more allowed DRIDs.

In some representative embodiments, the WTRU 102 may perform any of the following operations on a condition that the WTRU has not registered with the first network 205D before the first network 205D experiences a disaster condition: (1) Selecting a default or predetermined disaster response event identification (DRID) to register with the second network 205A; (2) Transmitting a registration request message to the second network entity 182A, the registration request message comprising information indicating the selected DRID or a portion of the selected DRID; and/or receive a registration accept message from the second network entity 182A if the WTRU 102 is within a portion of the second network 205A.

Figure 9 is a flow chart illustrating another exemplary method implemented by a WTRU that registers with a serving network after a disaster condition applicable to the WTRU's home network.

Referring to fig. 9, a representative method 900 may include: at block 910, the WTRU 102 receives information from the home network 205H indicating a value to be used during registration back to the home network 205H prior to registration with the serving network 205A. At block 920, the WTRU 102 may send information to the serving network 205A indicating the respective tracking area change of the WTRU 102 within the serving network 205A for each respective tracking area change. At block 930, the WTRU 102 may receive a message indicating that the WTRU 102 is to perform registration back to the home network 205H. At block 940, the WTRU 102 may perform registration back to the home network 205H according to the time associated with the indicated value.

In some representative embodiments, the tracking area list may include information indicative of a first tracking area TA-A1 of the serving network 205A and a second tracking area TA-A2 of the serving network 205A.

In some representative embodiments, the transmission of information indicating a change in the respective tracking area of the WTRU 102 within the serving network 205A may be initiated by a change in the WTRU 102 from a first location within the first tracking area TA-A1 to a second location within the second tracking area TA-A 2.

Fig. 10 is a flow chart illustrating an additional representative method implemented by a WTRU registered with a first network.

Referring to fig. 10, a representative method 1000 may include: at block 1010, the WTRU 102 receives information from the first network 205D indicating a value to be used during registration with another network 205A. At block 1020, the WTRU 102 may determine a first time window in which to perform registration with the other network 205A based at least on the indicated value. At block 1030, the WTRU 102 may begin registration with the other network 205A during a first time window. At block 1040, the WTRU 102 may perform any of the following operations, provided that registration is not completed during the first time window: (1) Suspending registration with the other network 205A, and/or starting a second registration or re-registration of the WTRU 102 with the other network 205A during a second time window.

In some representative embodiments, the receipt of information indicative of a value to be used during registration with other networks 205A may include receipt of a registration accept message, which may include information indicative of a timer value.

In some representative embodiments, the WTRU 102 may send and/or receive data transmissions via the other network 205A on the condition that registration is completed during the first time window.

In some representative embodiments, the determination of the first time window may include derivation of: (1) A start time and (2) one of an end time or a duration of a first time window, the end time or the duration of the first time window being based on: (i) the indicated value and any one of the following: (ii) a random value; or one or more parameters specific to WTRU 102.

Fig. 11 is a flow chart illustrating another exemplary method implemented by a WTRU registered with a first network.

Referring to fig. 11, a representative method 1100 may include: at block 1110, the WTRU 102 receives information from the first network 205D indicating a first value to be used during registration with another network 205A. At block 1120, the WTRU 102 may determine a first time window in which to perform registration with the other network 205A based at least on the indicated first value. At block 1130, the WTRU 102 may begin registration with the other network 205A during a first time window. At block 1140, the WTRU 102 may receive a message (e.g., an RRC connection reject message) from the other network 205A, the message including information indicating a second value to be used during a second registration with the other network 205A. At block 1150, the WTRU 102 may determine a second time window in which to perform a second registration with the other network 205A based at least on the indicated second value. At block 1160, the WTRU 102 may begin a second registration with the other network 205A during a second time window. At block 1170, the WTRU 102 may send or receive data transmissions via the other network 205A on the condition that the second registration is completed during the second time window.

Fig. 12 is a flow chart illustrating yet another exemplary method implemented by a WTRU.

Referring to fig. 12, a representative method 1200 may include: at block 1210, the WTRU 102 receives information indicating a bit string and a broadcast identity from the first network 205D. At block 1220, the WTRU 102 may use an algorithm to derive a WTRU identity based at least on the bit string and the broadcast identity to be used by the WTRU 102 when the disaster condition applies to the first network 205D. At block 1230, the WTRU 102 may receive information indicating that the disaster condition applies to the first network 205D. At block 1240, the WTRU 102 may register with another network 205A using the derived WTRU identity.

In some representative embodiments, the receipt of information indicating that the disaster condition applies to the first network 205D may include receipt of a paging message including information indicating that the disaster condition applies to the first network 205D.

Fig. 13 is a flow chart illustrating yet another exemplary method implemented by the WTRU 102 that registers with the serving network 205A after a disaster condition applies (e.g., has applied) to the home network 205H of the WTRU 102.

Referring to fig. 13, a representative method 1300 may include: at block 1310, the WTRU 102 receives information from the home network 205H indicating a value to be used during registration back to the home network 205H prior to registration with the serving network 205A. At block 1320, the WTRU 102 may receive a notification indicating that the disaster condition is no longer applicable to the home network 205H. At block 1330, the WTRU 102 may determine a first time window in which to perform registration back to the home network 205H based at least on the indicated value. At block 1340, the WTRU 102 may begin registration back to the home network 205H during a first time window. At block 1350, the WTRU 102 may perform any of the following operations, if registration is not complete during the first time window: (1) The registration back to the home network 205H is aborted and/or a second registration of the WTRU 102 back to the home network 205H during a second time window is initiated.

Fig. 14 is a flow chart illustrating a further additional exemplary method implemented by a WTRU.

Referring to fig. 14, the representative method 1400 may include: at block 1410, WTRU 102 receives configuration information indicating an event identity associated with a disaster response from first network entity 182D associated with first network 205D. At block 1420, the WTRU 102 may send a registration request message to the second network entity 182A of the second network 205A serving the WTRU 102, the registration request message including information indicating the event identity and the identity of the first network 205D. At block 1430, the WTRU 102 may receive a registration accept message.

In some representative embodiments, the registration request may include additional information indicating any of the following: (1) a location associated with the WTRU 102; (2) a disaster or coverage area associated with the WTRU 102; (3) one or more tracking areas associated with the WTRU 102; and/or (4) the last visited tracking area of WTRU 102.

In some representative embodiments, the configuration information may also indicate one or more tracking areas in which registration is not allowed.

In some representative embodiments, the WTRU 102 may determine that the current tracking area associated with the WTRU 102 does not match the one or more tracking areas indicated in the configuration information prior to sending the registration request message.

In some representative embodiments, the WTRU 102 may configure itself during the registration procedure to: (1) Determining whether the WTRU 102 has changed coverage area from a first TA associated with a received Tracking Area (TA) list to a second TA associated with the received TA list; and/or (2) send a non-access stratum message to the second network entity 182A indicating that the WTRU 102 has changed coverage area from a first TA associated with a received Tracking Area (TA) list to a second TA associated with the received TA list. For example, the non-access stratum message may include service type information indicating that the non-access stratum message is provided to the second network 205A to inform the second network 205A of the location of the WTRU.

Fig. 15 is a flow chart illustrating yet another additional exemplary method implemented by a WTRU.

Referring to fig. 15, a representative method 1500 may include: at block 1510, WTRU 102 receives configuration information from a first network entity 182D associated with first network 205D, the configuration information indicating one or more disaster response event identifications (DRIDs) associated with disaster responses. At block 1520, the WTRU 102 may receive broadcast information from the second network entity 182A of the second network 205A indicating one or more allowed DRIDs or portions thereof. At block 1530, the WTRU 102 may select a DRID of the indicated DRIDs that matches the one or more allowed DRIDs or portions thereof. At block 1540, the WTRU 102 may send a registration request message to the second network entity 182A including information indicating the selected DRID or a portion of the selected DRID. At block 1550, the WTRU 102 may receive a registration accept message from the second network entity 182A on condition that the WTRU 102 is within a portion of the second network 205A.

In certain representative embodiments, the selected DRID may include an Area Identification (AID) corresponding to a disaster response service area as part of the second network 205A, the AID being used for registration during disaster conditions associated with the first network 205D.

In some representative embodiments, the WTRU 205 may be within the disaster-response service area of the second network 205A when the WTRU 102 is any of the following: (1) Within one or more particular tracking areas of the second network 205A; (2) Within one or more particular cells of the second network 205A; (3) In proximity to one or more particular RAN nodes of the second network 205A; (4) being within a particular coverage area of the second network 205A; (5) being within the entire coverage area of the second network 205A; and/or (6) in the vicinity of any RAN node of the second network 205A.

Fig. 16 is a flow chart illustrating a representative method implemented by a Network Entity (NE) (e.g., AUSF/UDM/DRF).

Referring to fig. 16, the representative method 1600 may include: at block 1610, NE 210D of the first network 205D sends configuration information to WTRU 102 (via NE 182D) indicating an event identification associated with the disaster response. At block 1620, NE 210D of the first network 205D may receive a message (from NE 182A) via the second network 205A to serve WTRU 102 indicating any of the following: (1) An event identification and an identification of a second network 205A to serve the WTRU 102; and/or (2) an identity of a first network 205D serving the WTRU 102 and an identity of a second network 205A serving the WTRU 102. At block 1630, the NE 210D of the first network 205D may send a message to the second network 205A to initiate authentication of the WTRU 102, provided the event identification and the second network 205A are authorized.

In some representative embodiments, NE 210D may receive information indicating the location of WTRU 102 during the disaster condition; and may initiate authentication of the WTRU 102 based at least on the location of the WTRU 102 during the disaster condition.

Systems and methods for processing data according to representative embodiments may be performed by one or more processors executing sequences of instructions contained in a memory device. Such instructions may be read into the memory device from other computer-readable media, such as an auxiliary data storage device. Execution of the sequences of instructions contained in the memory device causes the processor to perform operations such as those described above. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Such software may run remotely on a processor housed within a robotic assistance/appliance (RAA) and/or another mobile device. In the latter case, data may be transmitted between the RAA or other mobile device containing the sensor and a remote device containing a processor running software that performs the ratio estimation and compensation as described above, either by wire or wirelessly. According to other representative embodiments, some of the processing described above with respect to positioning may be performed in the sensor/camera-containing device, while the remainder of the processing may be performed in the second device after receiving the partially processed data from the sensor/camera-containing device.

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for the WTRU 102, WTRU, terminal, base station, RNC, or any host computer.

Furthermore, in the above embodiments, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.

Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit. It should be understood that the representative embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.

The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the representative embodiments are not limited to the above-described memories, and that other platforms and memories may support the described methods. It should be understood that the representative embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.

In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of the mobile unit, the network element, and/or any other computing device.

There is little distinction between hardware implementations and software implementations of aspects of the system. The use of hardware or software is often (but not always, as in some contexts the choice between hardware and software may become important) a design choice representing a tradeoff between cost and efficiency. There may be various media (e.g., hardware, software, and/or firmware) that may implement the processes and/or systems and/or other techniques described herein, and the preferred media may vary with the context in which the processes and/or systems and/or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a medium of mainly hardware and/or firmware. If flexibility is paramount, the implementer may opt for a particular implementation of mainly software. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Where such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.

The present disclosure is not limited to the specific embodiments described in this patent application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the application, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the application unless explicitly described as such. Functionally equivalent methods and apparatus, other than those enumerated herein, which are within the scope of the present disclosure, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the terms "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean, as referred to herein: (i) A wireless transmit and/or receive unit (WTRU), such as described below; (ii) Any of several embodiments of the WTRU, such as those described below; (iii) Devices with wireless capabilities and/or with wired capabilities (e.g., tethered) are configured with some or all of the structure and functionality of a WTRU, in particular, such as described below; (iii) A wireless-capable and/or wireline-capable device may be configured with less than all of the structure and functionality of a WTRU, such as described below; or (iv) etc. Details of an exemplary WTRU that may represent any of the WTRUs described herein are provided below with respect to fig. 1A-1D.

In certain representative implementations, portions of the subject matter described herein can be implemented via an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), and/or other integrated format. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media such as digital and/or analog communications media (e.g., fiber optic cable, waveguide, wired communications link, wireless communications link, etc.).

The subject matter described herein sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, physically mateable and/or physically interactable components and/or wirelessly interactable components and/or logically interactable components.

With respect to substantially any plural and/or singular terms used herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly listed herein.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will be further understood by those with skill in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the following appended claims and/or the description herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation object by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation object to embodiments containing only one such recitation object. Even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). In addition, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). It should also be understood by those within the art that virtually any separate word and/or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B". In addition, as used herein, the term "…" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" or "group" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero.

Additionally, where features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will recognize thereby that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.

As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as sufficiently descriptive and so that the same range can be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, and the like. As will also be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc., include the recited numbers and refer to ranges that may be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the scope includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, or the like.

Furthermore, the claims should not be read as limited to the order or elements provided, unless stated to that effect. In addition, use of the term "means for …" in any claim is intended to invoke 35U.S. C. ≡112,6 or device plus function claims format, and any claims without the term "device for …" are not intended to be so.

A processor associated with software may be used to implement a radio frequency transceiver in a Wireless Transmit Receive Unit (WTRU), user Equipment (UE), terminal, base station, mobility Management Entity (MME), or evolved packet coreUse in the heart (EPC) or any host. The WTRU may be used in combination with a module, and may be implemented in hardware and/or software including: software Defined Radio (SDR) and other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, and the like,A module, a Frequency Modulation (FM) radio unit, a Near Field Communication (NFC) module, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Throughout this disclosure, those skilled in the art will appreciate that certain representative embodiments can be used in alternative forms or in combination with other representative embodiments.

Additionally, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium as instructions for a computer or processor to perform the actions described above. Examples of non-transitory computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method implemented by a wireless transmit/receive unit (WTRU) registered with a first network, the method comprising:

receiving information from the first network indicating a value to be used during registration with a second network;

determining at least a first start time and a second start time from which to perform the registration with the second network based at least on the indicated value;

Initiating the registration with the second network after the first start time; and

on condition that the registration is not completed within a defined period after the first start time:

(1) Suspending the registration with the second network, and

(2) A second registration or re-registration of the WTRU with the second network is initiated after the second start time.

2. The method according to claim 1, wherein:

the received information indicating the value also indicates a time window;

the defined period is based on the duration of the time window, and

the method further includes determining the time window based on one of (1) the first start time and (2) the following: an end time or the duration of the time window, the end time or the duration of the time window being based on: (i) the indicated value and any one of the following: (ii) A random value or one or more parameters specific to the WTRU.

3. The method of any preceding claim, wherein the received information further indicates an identity of the WTRU.

4. The method of any preceding claim, wherein:

When the first network is not reachable by the second network, the WTRU roams to the second network as a disaster roamer; and is also provided with

The received information also indicates a second value to be used in determining when to allow the WTRU to access the first network or the further network to which the WTRU was registered prior to the first network or the further network.

5. The method of any preceding claim, further comprising: transmitting or receiving a data transmission via the second network under the following conditions: (1) The registration is completed during the defined period, or (2) the second registration or the re-registration is completed after the second start time.

6. The method of any preceding claim, further comprising determining that the registration is not complete based on any of: (1) Receiving a registration reject message from the network entity comprising information indicating that the registration is rejected, or (2) not receiving a registration accept message within the defined period.

7. The method of any preceding claim, further comprising receiving, by the WTRU, information indicating: (1) A disaster condition applicable to the first network, and (2) a second value to be used to determine when to allow the WTRU to register or re-register with the first network after the disaster condition is no longer applicable to the first network.

8. The method of any preceding claim, wherein the initiating of any of (1) the registration, (2) the second registration, or (3) the re-registration comprises sending, by the WTRU, a registration request message to a network entity of the second network to serve the WTRU, the registration request message including information indicating any of: (1) Event identification, (2) identification of the first network, any of the following: (i) a location associated with the WTRU; (ii) a disaster or coverage area associated with the WTRU;

(iii) One or more tracking areas associated with the WTRU; and/or (iv) a last visited tracking area of the WTRU.

9. The method of any preceding claim, further comprising configuring the WTRU to, on the condition that the WTRU supports a service interruption minimization (mit) operation:

determining whether the WTRU has changed coverage area from a first TA associated with a received Tracking Area (TA) list to a second TA associated with the received TA list;

transmitting a non-access stratum message to a network entity of the first network, the non-access stratum message indicating that the WTRU has changed the coverage area from the first TA to the second TA;

Receiving an indication to re-register with the second network with which the WTRU was previously registered; and

re-registering with the second network by the WTRU.

10. The method of any preceding claim, further comprising:

transmitting, by the WTRU, information indicating a disaster roaming indication by the WTRU during a disaster condition; and

a message is received by the WTRU to initiate authentication of the WTRU based at least on the disaster roaming indication.

11. The method of any preceding claim, wherein the receiving of information indicative of the value to be used during the registration with the second network comprises receiving configuration information from a first network entity associated with the first network, the configuration information being indicative of one or more disaster response event identifications (DRIDs) associated with one or more disaster responses, the method further comprising:

receiving, by the WTRU, broadcast information indicating one or more allowed DRIDs or portions thereof from a second network entity of the second network;

selecting, by the WTRU, a DRID of the indicated DRIDs that matches the one or more allowed DRIDs or portions thereof;

Transmitting, by the WTRU, a registration request message to the second network entity, the registration request message including information indicating the selected DRID or a portion of the selected DRID; and

a registration accept message is received by the WTRU from the second network entity under a condition that the WTRU is within a portion of the second network.

12. The method according to claim 11, wherein:

the selected DRID includes an Area Identification (AID) corresponding to a disaster response service area as part of the second network, the AID to be used for the registration during a disaster condition associated with the first network; and is also provided with

The WTRU is within the disaster response service area of the second network when the WTRU is any one of: (1) Within one or more particular tracking areas of the second network; (2) Is within one or more particular cells of the second network; (3) In proximity to one or more particular Radio Access Network (RAN) nodes of the second network; (4) being within a particular coverage area of the second network; (5) being within the entire coverage area of the second network; or (6) in the vicinity of any RAN node of the second network.

13. The method of claim 11, wherein each DRID includes a Disaster Recovery Code (DRC) such that the selection of the DRID of the indicated DRIDs is based on a match of one of the DRCs of the indicated DRIDs with one of the one or more allowed DRIDs.

14. The method of any preceding claim, further comprising, on a condition that the WTRU has not registered with the first network before the first network experiences the disaster condition:

selecting, by the WTRU, a default or predetermined disaster response event identification (DRID) to register with the second network;

a registration accept message is received by the WTRU from a second network entity under a condition that the WTRU is within a portion of the second network.

15. The method of any preceding claim, wherein the suspension of the registration with the second network comprises: the received registration accept message is ignored or not acted upon on condition that the registration accept message is received during a period after completion of the defined period and before the second start time.

16. A wireless transmit/receive unit (WTRU) registered with a first network, the WTRU comprising:

a transmitter/receiver unit configured to receive information from the first network indicating a value to be used during registration with a second network; and

a processor configured to:

determining at least a first start time and a second start time from which to perform the registration with the second network based at least on the indicated value,

(1) Suspending the registration with the second network, and

17. The WTRU of claim 16, wherein:

the received information indicating the value also indicates a time window; and is also provided with

The defined period is based on a duration of the time window.

The processor is configured to determine the time window based on one of (1) the first start time and (2) the following: the duration of an end time or first time window, the duration of the end time or first time window based on: (i) the indicated value and any one of the following: (ii) A random value or one or more parameters specific to the WTRU.

18. The WTRU of any of claims 16-17, wherein the received information further indicates an identity of the WTRU.

19. The WTRU of any one of claims 16 to 18, wherein:

the WTRU is configured to roam to the second network as a disaster roamer when the first network is not reachable by the second network; and is also provided with

20. The WTRU of any one of claims 16 to 19, wherein the transmitter/receiver unit is configured to send or receive data transmissions via the second network on the condition that: (1) The registration is completed during the defined period, or (2) the second registration or the re-registration is completed after the second start time.

21. The WTRU of any one of claims 16-20, wherein the processor is configured to determine that the registration is not complete based on any one of: (1) Receiving a registration reject message from the network entity comprising information indicating that the registration is rejected, or (2) not receiving a registration accept message within the defined period.

22. The WTRU of any one of claims 16 to 21, wherein the transmitter/receiver unit is configured to receive information indicating: (1) A disaster condition applicable to the first network, and (2) a second value to be used to determine when to allow the WTRU to register or re-register with the first network after the disaster condition is no longer applicable to the first network.

23. The WTRU of any of claims 16-22, wherein the transmitter/receiver unit is configured to send a registration request message to a network entity of the second network to serve the WTRU, the registration request message including information indicating any of: (1) Event identification, (2) identification of the first network, any of the following: (i) a location associated with the WTRU; (ii) a disaster or coverage area associated with the WTRU; (iii) One or more tracking areas associated with the WTRU; and/or (iv) a last visited tracking area of the WTRU.

24. The WTRU of any one of claims 16 to 23, wherein:

on the condition that the WTRU supports a service interruption minimization (mit) operation:

The processor is configured to determine whether the WTRU has changed coverage area from a first Tracking Area (TA) associated with a received TA list to a second TA associated with the received TA list;

the transmitter/receiver unit is configured to:

transmitting a non-access stratum message to a network entity of the first network, the non-access stratum message indicating that the WTRU has changed the coverage area from the first TA to the second TA, and

receiving an indication to re-register with the second network with which the WTRU was previously registered; and is also provided with

The processor is configured to re-register with the second network by the WTRU.

25. The WTRU of any one of claims 16 to 24, wherein the transmitter/receiver unit is configured to:

transmitting information indicating a disaster roaming indication by the WTRU during a disaster condition; and

a message is received to initiate authentication of the WTRU based at least on the disaster roaming indication.

26. The WTRU of any one of claims 16 to 24, wherein:

the transmitter/receiver unit is configured to:

receiving configuration information from a first network entity associated with the first network, the configuration information indicating one or more disaster response event identifications (DRIDs) associated with one or more disaster responses, and

Receiving broadcast information indicating one or more allowed DRIDs or portions thereof from a second network entity of the second network;

the processor is configured to select a DRID of the indicated DRIDs that matches the one or more allowed DRIDs or portions thereof; and is also provided with

The transmitter/receiver unit is configured to:

transmitting a registration request message to the second network entity, the registration request message including information indicating the selected DRID or a part of the selected DRID, and

a registration accept message is received from the second network entity if the WTRU is within a portion of the second network.

27. The WTRU of claim 26, wherein:

the selected DRID includes an Area Identification (AID) corresponding to a disaster response service area as part of the second network, the AID to be used for registration during a disaster condition associated with the first network; and is also provided with

The WTRU is within the disaster response service area of the second network when the WTRU is any one of: (1) Within one or more particular tracking areas of the second network; (2) Is within one or more particular cells of the second network;

(3) In proximity to one or more particular Radio Access Network (RAN) nodes of the second network; (4) being within a particular coverage area of the second network; (5) being within the entire coverage area of the second network; and/or (6) being in proximity of any RAN node of the second network.

28. The WTRU of any one of claims 26 to 27 wherein each DRID includes a Disaster Recovery Code (DRC) such that the processor is configured to select one of the indicated DRIDs based on a match of the DRC with the DRC of one of the one or more allowed DRIDs.

29. The WTRU of any one of claims 16 to 28, wherein:

the processor is configured to: selecting a default or predetermined disaster response event identification (DRID) to register with the second network on a condition that the WTRU has not registered with the first network before the first network experiences a disaster condition; and is also provided with

The transmitter/receiver unit is configured to:

transmitting a registration request message to the second network entity, the registration request message comprising information indicating the selected DRID or a part of the selected DRID, and

30. The WTRU of any one of claims 16 to 29, wherein the processor is configured to: the received registration acceptance message is ignored or not acted upon on condition that the received registration acceptance message is received during a period after completion of the defined period and before the second start time.