WO2024172564A1

WO2024172564A1 - Communication related to localized service

Info

Publication number: WO2024172564A1
Application number: PCT/KR2024/095221
Authority: WO
Inventors: Hyunjung CHOE; Hyunsook Kim; Laeyoung Kim
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2023-02-16
Filing date: 2024-02-15
Publication date: 2024-08-22
Anticipated expiration: 2025-08-16
Also published as: EP4666611A1

Abstract

The present disclosure provides a method performed by a UE. The method may include: receiving Steering of Roaming (SoR) information including localized service information from an Access and Mobility Function (AMF); and selecting a network based on the SoR information, wherein the SoR information includes a plurality of time information related to the localized service information, and wherein the selecting is performed based on the plurality of time information and localized service information for a recurrent event.

Description

[Rectified under Rule 91, 13.03.2024]COMMUNICATION RELATED TO LOCALIZED SERVICE

The present specification relates to a radio communication.

3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) is a technology for enabling high-speed packet communications. Many schemes have been proposed for the LTE objective including those that aim to reduce user and provider costs, improve service quality, and expand and improve coverage and system capacity. The 3GPP LTE requires reduced cost per bit, increased service availability, flexible use of a frequency band, a simple structure, an open interface, and adequate power consumption of a terminal as an upper-level requirement.

Work has started in International Telecommunication Union (ITU) and 3GPP to develop requirements and specifications for New Radio (NR) systems. 3GPP has to identify and develop the technology components needed for successfully standardizing the new RAT timely satisfying both the urgent market needs, and the more long-term requirements set forth by the ITU Radio communication sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. Further, the NR should be able to use any spectrum band ranging at least up to 100 GHz that may be made available for wireless communications even in a more distant future.

The NR targets a single technical framework addressing all usage scenarios, requirements and deployment scenarios including enhanced Mobile BroadBand (eMBB), massive Machine Type Communications (mMTC), Ultra-Reliable and Low Latency Communications (URLLC), etc. The NR shall be inherently forward compatible.

In prior arts, network transmits SoR(Steering of Roaming) information to a UE. The UE performs network selection based on the SoR informaiton. However, there are problems that recurrent events cannot be performed efficiently.

In one aspect, a method performed by a UE is provided. The method may comprise receiving SoR information including localized service information from an AMF; and selecting a network based on the SoR information.

In another aspect, an appartus performing the above method is provided.

In one aspect, a method performed by an AMF is provided. The method may comprise receiving a registration request message from a UE; and transmitting a registration accept messag to the UE

In another aspect, an appartus performing the above method is provided.

FIG. 1 shows an example of a communication system to which implementations of the present disclosure is applied.

FIG. 2 shows an example of wireless devices to which implementations of the present disclosure is applied.

FIG. 3 shows an example of UE to which implementations of the present disclosure is applied.

FIG. 4 shows an example of 5G system architecture to which implementations of the present disclosure is applied.

FIGS. 5 and 6 show an example of a registration procedure to which implementations of the present disclosure is applied.

FIG. 7 illustrates an example of Procedure for configuring UE with SOR-CMCI after registration according to an embodiment of the present disclosure.

FIGS. 8a and 8b illustrates an example of Procedure for providing SOR-SNPN-SI during registration according to an embodiment of the present disclosure.

FIG. 9 illustrates an example of operations of UE based on SoR information according to an embodiment of the present disclosure.

FIG. 10 illustrates an example of a periodicity and a duration of an event according to an embodiment of the present disclosure.

FIGS. 11a to 11c illustrates an example of a UE and an overall procedure according to an embodiment of the present disclosure.

FIGS. 12a and 12b illustrates an example of operations perforemd by a UE and an AMF according to an embodiment of the present disclosure.

FIG. 13 shows an example of a scenario according to the present disclosure.

FIG. 14 illustrates an example of second example scenario according to an embodiment of the present disclosure.

FIG. 15 illustrates an example of an operation according to an embodiment of the present disclosure.

The following techniques, apparatuses, and systems may be applied to a variety of wireless multiple access systems. Examples of the multiple access systems include a Code Division Multiple Access (CDMA) system, a Frequency Division Multiple Access (FDMA) system, a Time Division Multiple Access (TDMA) system, an Orthogonal Frequency Division Multiple Access (OFDMA) system, a Single Carrier Frequency Division Multiple Access (SC-FDMA) system, and a Multi Carrier Frequency Division Multiple Access (MC-FDMA) system. CDMA may be embodied through radio technology such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA may be embodied through radio technology such as Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data rates for GSM Evolution (EDGE). OFDMA may be embodied through radio technology such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA). UTRA is a part of a Universal Mobile Telecommunications System (UMTS). 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) is a part of Evolved UMTS (E-UMTS) using E-UTRA. 3GPP LTE employs OFDMA in downlink (DL) and SC-FDMA in uplink (UL). Evolution of 3GPP LTE includes LTE-Advanced (LTE-A), LTE-A Pro, and/or 5G New Radio (NR).

For convenience of description, implementations of the present disclosure are mainly described in regards to a 3GPP based wireless communication system. However, the technical features of the present disclosure are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP based wireless communication system, aspects of the present disclosure that are not limited to 3GPP based wireless communication system are applicable to other mobile communication systems.

For terms and technologies which are not specifically described among the terms of and technologies employed in the present disclosure, the wireless communication standard documents published before the present disclosure may be referenced.

In the present disclosure, "A or B" may mean "only A", "only B", or "both A and B". In other words, "A or B" in the present disclosure may be interpreted as "A and/or B". For example, "A, B or C" in the present disclosure may mean "only A", "only B", "only C", or "any combination of A, B and C".

In the present disclosure, slash (/) or comma (,) may mean "and/or". For example, "A/B" may mean "A and/or B". Accordingly, "A/B" may mean "only A", "only B", or "both A and B". For example, "A, B, C" may mean "A, B or C".

In the present disclosure, "at least one of A and B" may mean "only A", "only B" or "both A and B". In addition, the expression "at least one of A or B" or "at least one of A and/or B" in the present disclosure may be interpreted as same as "at least one of A and B".

In addition, in the present disclosure, "at least one of A, B and C" may mean "only A", "only B", "only C", or "any combination of A, B and C". In addition, "at least one of A, B or C" or "at least one of A, B and/or C" may mean "at least one of A, B and C".

Also, parentheses used in the present disclosure may mean "for example". In detail, when it is shown as "control information (PDCCH)", "PDCCH" may be proposed as an example of "control information". In other words, "control information" in the present disclosure is not limited to "PDCCH", and "PDCCH" may be proposed as an example of "control information". In addition, even when shown as "control information (i.e., PDCCH)", "PDCCH" may be proposed as an example of "control information".

Technical features that are separately described in one drawing in the present disclosure may be implemented separately or simultaneously.

Although not limited thereto, various descriptions, functions, procedures, suggestions, methods and/or operational flowcharts of the present disclosure disclosed herein can be applied to various fields requiring wireless communication and/or connection (e.g., 5G) between devices.

Hereinafter, the present disclosure will be described in more detail with reference to drawings. The same reference numerals in the following drawings and/or descriptions may refer to the same and/or corresponding hardware blocks, software blocks, and/or functional blocks unless otherwise indicated.

The 5G usage scenarios shown in FIG. 1 are only exemplary, and the technical features of the present disclosure can be applied to other 5G usage scenarios which are not shown in FIG. 1.

Three main requirement categories for 5G include (1) a category of enhanced Mobile BroadBand (eMBB), (2) a category of massive Machine Type Communication (mMTC), and (3) a category of Ultra-Reliable and Low Latency Communications (URLLC).

Referring to FIG. 1, the communication system 1 includes wireless devices 100a to 100f, Base Stations (BSs) 200, and a network 300. Although FIG. 1 illustrates a 5G network as an example of the network of the communication system 1, the implementations of the present disclosure are not limited to the 5G system, and can be applied to the future communication system beyond the 5G system.

The BSs 200 and the network 300 may be implemented as wireless devices and a specific wireless device may operate as a BS/network node with respect to other wireless devices.

The wireless devices 100a to 100f represent devices performing communication using Radio Access Technology (RAT) (e.g., 5G NR or LTE) and may be referred to as communication/radio/5G devices. The wireless devices 100a to 100f may include, without being limited to, a robot 100a, vehicles 100b-1 and 100b-2, an eXtended Reality (XR) device 100c, a hand-held device 100d, a home appliance 100e, an Internet-of-Things (IoT) device 100f, and an Artificial Intelligence (AI) device/server 400. For example, the vehicles may include a vehicle having a wireless communication function, an autonomous driving vehicle, and a vehicle capable of performing communication between vehicles. The vehicles may include an Unmanned Aerial Vehicle (UAV) (e.g., a drone). The XR device may include an Augmented Reality (AR)/Virtual Reality (VR)/Mixed Reality (MR) device and may be implemented in the form of a Head-Mounted Device (HMD), a Head-Up Display (HUD) mounted in a vehicle, a television, a smartphone, a computer, a wearable device, a home appliance device, a digital signage, a vehicle, a robot, etc. The hand-held device may include a smartphone, a smartpad, a wearable device (e.g., a smartwatch or a smartglasses), and a computer (e.g., a notebook). The home appliance may include a TV, a refrigerator, and a washing machine. The IoT device may include a sensor and a smartmeter.

In the present disclosure, the wireless devices 100a to 100f may be called User Equipments (UEs). A UE may include, for example, a cellular phone, a smartphone, a laptop computer, a digital broadcast terminal, a Personal Digital Assistant (PDA), a Portable Multimedia Player (PMP), a navigation system, a slate Personal Computer (PC), a tablet PC, an ultrabook, a vehicle, a vehicle having an autonomous traveling function, a connected car, an UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a FinTech device (or a financial device), a security device, a weather/environment device, a device related to a 5G service, or a device related to a fourth industrial revolution field.

The wireless devices 100a to 100f may be connected to the network 300 via the BSs 200. An AI technology may be applied to the wireless devices 100a to 100f and the wireless devices 100a to 100f may be connected to the AI server 400 via the network 300. The network 300 may be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a beyond-5G network. Although the wireless devices 100a to 100f may communicate with each other through the BSs 200/network 300, the wireless devices 100a to 100f may perform direct communication (e.g., sidelink communication) with each other without passing through the BSs 200/network 300. For example, the vehicles 100b-1 and 100b-2 may perform direct communication (e.g., Vehicle-to-Vehicle (V2V)/Vehicle-to-everything (V2X) communication). The IoT device (e.g., a sensor) may perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

Wireless communication/

connections

150a, 150b and 150c may be established between the wireless devices 100a to 100f and/or between wireless device 100a to 100f and BS 200 and/or between BSs 200. Herein, the wireless communication/connections may be established through various RATs (e.g., 5G NR) such as uplink/downlink communication 150a, sidelink communication (or Device-to-Device (D2D) communication) 150b, inter-base station communication 150c (e.g., relay, Integrated Access and Backhaul (IAB)), etc. The wireless devices 100a to 100f and the BSs 200/the wireless devices 100a to 100f may transmit/receive radio signals to/from each other through the wireless communication/

connections

150a, 150b and 150c. For example, the wireless communication/

connections

150a, 150b and 150c may transmit/receive signals through various physical channels. To this end, at least a part of various configuration information configuring processes, various signal processing processes (e.g., channel encoding/decoding, modulation/demodulation, and resource mapping/de-mapping), and resource allocating processes, for transmitting/receiving radio signals, may be performed based on the various proposals of the present disclosure.

NR supports multiples numerologies (and/or multiple Sub-Carrier Spacings (SCS)) to support various 5G services. For example, if SCS is 15 kHz, wide area can be supported in traditional cellular bands, and if SCS is 30 kHz/60 kHz, dense-urban, lower latency, and wider carrier bandwidth can be supported. If SCS is 60 kHz or higher, bandwidths greater than 24.25 GHz can be supported to overcome phase noise.

The NR frequency band may be defined as two types of frequency range, i.e., Frequency Range 1 (FR1) and Frequency Range 2 (FR2). The numerical value of the frequency range may be changed. For example, the frequency ranges of the two types (FR1 and FR2) may be as shown in Table 1 below. For ease of explanation, in the frequency ranges used in the NR system, FR1 may mean "sub 6 GHz range", FR2 may mean "above 6 GHz range," and may be referred to as millimeter Wave (mmW).

Frequency Range designation	Corresponding frequency range	Subcarrier Spacing
FR1	450MHz - 6000MHz	15, 30, 60kHz
FR2	24250MHz - 52600MHz	60, 120, 240kHz

As mentioned above, the numerical value of the frequency range of the NR system may be changed. For example, FR1 may include a frequency band of 410MHz to 7125MHz as shown in Table 2 below. That is, FR1 may include a frequency band of 6GHz (or 5850, 5900, 5925 MHz, etc.) or more. For example, a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or more included in FR1 may include an unlicensed band. Unlicensed bands may be used for a variety of purposes, for example for communication for vehicles (e.g., autonomous driving).

Frequency Range designation	Corresponding frequency range	Subcarrier Spacing
FR1	410MHz - 7125MHz	15, 30, 60kHz
FR2	24250MHz - 52600MHz	60, 120, 240kHz

Here, the radio communication technologies implemented in the wireless devices in the present disclosure may include NarrowBand IoT (NB-IoT) technology for low-power communication as well as LTE, NR and 6G. For example, NB-IoT technology may be an example of Low Power Wide Area Network (LPWAN) technology, may be implemented in specifications such as LTE Cat NB1 and/or LTE Cat NB2, and may not be limited to the above-mentioned names. Additionally and/or alternatively, the radio communication technologies implemented in the wireless devices in the present disclosure may communicate based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and be called by various names such as enhanced MTC (eMTC). For example, LTE-M technology may be implemented in at least one of the various specifications, such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-bandwidth limited (non-BL), 5) LTE-MTC, 6) LTE Machine Type Communication, and/or 7) LTE M, and may not be limited to the above-mentioned names. Additionally and/or alternatively, the radio communication technologies implemented in the wireless devices in the present disclosure may include at least one of ZigBee, Bluetooth, and/or LPWAN which take into account low-power communication, and may not be limited to the above-mentioned names. For example, ZigBee technology may generate Personal Area Networks (PANs) associated with small/low-power digital communication based on various specifications such as IEEE 802.15.4 and may be called various names.

In FIG. 2, The first wireless device 100 and/or the second wireless device 200 may be implemented in various forms according to use cases/services. For example, {the first wireless device 100 and the second wireless device 200} may correspond to at least one of {the wireless device 100a to 100f and the BS 200}, {the wireless device 100a to 100f and the wireless device 100a to 100f} and/or {the BS 200 and the BS 200} of FIG. 1. The first wireless device 100 and/or the second wireless device 200 may be configured by various elements, devices/parts, and/or modules.

The first wireless device 100 may include at least one transceiver, such as a transceiver 106, at least one processing chip, such as a processing chip 101, and/or one or more antennas 108.

The processing chip 101 may include at least one processor, such a processor 102, and at least one memory, such as a memory 104. Additional and/or alternatively, the memory 104 may be placed outside of the processing chip 101.

The processor 102 may control the memory 104 and/or the transceiver 106 and may be adapted to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts described in the present disclosure. For example, the processor 102 may process information within the memory 104 to generate first information/signals and then transmit radio signals including the first information/signals through the transceiver 106. The processor 102 may receive radio signals including second information/signals through the transceiver 106 and then store information obtained by processing the second information/signals in the memory 104.

The memory 104 may be operably connectable to the processor 102. The memory 104 may store various types of information and/or instructions. The memory 104 may store a firmware and/or a software code 105 which implements codes, commands, and/or a set of commands that, when executed by the processor 102, perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. For example, the firmware and/or the software code 105 may implement instructions that, when executed by the processor 102, perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. For example, the firmware and/or the software code 105 may control the processor 102 to perform one or more protocols. For example, the firmware and/or the software code 105 may control the processor 102 to perform one or more layers of the radio interface protocol.

Herein, the processor 102 and the memory 104 may be a part of a communication modem/circuit/chip designed to implement RAT (e.g., LTE or NR). The transceiver 106 may be connected to the processor 102 and transmit and/or receive radio signals through one or more antennas 108. Each of the transceiver 106 may include a transmitter and/or a receiver. The transceiver 106 may be interchangeably used with Radio Frequency (RF) unit(s). In the present disclosure, the first wireless device 100 may represent a communication modem/circuit/chip.

The second wireless device 200 may include at least one transceiver, such as a transceiver 206, at least one processing chip, such as a processing chip 201, and/or one or more antennas 208.

The processing chip 201 may include at least one processor, such a processor 202, and at least one memory, such as a memory 204. Additional and/or alternatively, the memory 204 may be placed outside of the processing chip 201.

The processor 202 may control the memory 204 and/or the transceiver 206 and may be adapted to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts described in the present disclosure. For example, the processor 202 may process information within the memory 204 to generate third information/signals and then transmit radio signals including the third information/signals through the transceiver 206. The processor 202 may receive radio signals including fourth information/signals through the transceiver 106 and then store information obtained by processing the fourth information/signals in the memory 204.

The memory 204 may be operably connectable to the processor 202. The memory 204 may store various types of information and/or instructions. The memory 204 may store a firmware and/or a software code 205 which implements codes, commands, and/or a set of commands that, when executed by the processor 202, perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. For example, the firmware and/or the software code 205 may implement instructions that, when executed by the processor 202, perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. For example, the firmware and/or the software code 205 may control the processor 202 to perform one or more protocols. For example, the firmware and/or the software code 205 may control the processor 202 to perform one or more layers of the radio interface protocol.

Herein, the processor 202 and the memory 204 may be a part of a communication modem/circuit/chip designed to implement RAT (e.g., LTE or NR). The transceiver 206 may be connected to the processor 202 and transmit and/or receive radio signals through one or more antennas 208. Each of the transceiver 206 may include a transmitter and/or a receiver. The transceiver 206 may be interchangeably used with RF unit. In the present disclosure, the second wireless device 200 may represent a communication modem/circuit/chip.

Hereinafter, hardware elements of the

wireless devices

100 and 200 will be described more specifically. One or more protocol layers may be implemented by, without being limited to, one or

more processors

102 and 202. For example, the one or

more processors

102 and 202 may implement one or more layers (e.g., functional layers such as Physical (PHY) layer, Media Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC) layer, and Service Data Adaptation Protocol (SDAP) layer). The one or

more processors

102 and 202 may generate one or more Protocol Data Units (PDUs), one or more Service Data Unit (SDUs), messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. The one or

more processors

102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure and provide the generated signals to the one or

more transceivers

106 and 206. The one or

more processors

102 and 202 may receive the signals (e.g., baseband signals) from the one or

more transceivers

106 and 206 and acquire the PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure.

The one or

more processors

102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. The one or

more processors

102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. As an example, one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), one or more Digital Signal Processing Devices (DSPDs), one or more Programmable Logic Devices (PLDs), or one or more Field Programmable Gate Arrays (FPGAs) may be included in the one or

more processors

102 and 202. For example, the one or

more processors

102 and 202 may be configured by a set of a communication control processor, an Application Processor (AP), an Electronic Control Unit (ECU), a Central Processing Unit (CPU), a Graphic Processing Unit (GPU), and a memory control processor.

The one or

more memories

104 and 204 may be connected to the one or

more processors

102 and 202 and store various types of data, signals, messages, information, programs, code, instructions, and/or commands. The one or

more memories

104 and 204 may be configured by Random Access Memory (RAM), Dynamic RAM (DRAM), Read-Only Memory (ROM), electrically Erasable Programmable Read-Only Memory (EPROM), flash memory, volatile memory, non-volatile memory, hard drive, register, cash memory, computer-readable storage medium, and/or combinations thereof. The one or

more memories

104 and 204 may be located at the interior and/or exterior of the one or

more processors

102 and 202. The one or

more memories

104 and 204 may be connected to the one or

more processors

102 and 202 through various technologies such as wired or wireless connection.

The one or

more transceivers

106 and 206 may transmit user data, control information, and/or radio signals/channels, mentioned in the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure, to one or more other devices. The one or

more transceivers

106 and 206 may receive user data, control information, and/or radio signals/channels, mentioned in the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure, from one or more other devices. For example, the one or

more transceivers

106 and 206 may be connected to the one or

more processors

102 and 202 and transmit and receive radio signals. For example, the one or

more processors

102 and 202 may perform control so that the one or

more transceivers

106 and 206 may transmit user data, control information, or radio signals to one or more other devices. The one or

more processors

102 and 202 may perform control so that the one or

more transceivers

106 and 206 may receive user data, control information, or radio signals from one or more other devices.

The one or

more transceivers

106 and 206 may be connected to the one or

more antennas

108 and 208. Additionally and/or alternatively, the one or

more transceivers

106 and 206 may include one or

more antennas

108 and 208. The one or

more transceivers

106 and 206 may be adapted to transmit and receive user data, control information, and/or radio signals/channels, mentioned in the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure, through the one or

more antennas

108 and 208. In the present disclosure, the one or

more antennas

108 and 208 may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

The one or

more transceivers

106 and 206 may convert received user data, control information, radio signals/channels, etc., from RF band signals into baseband signals in order to process received user data, control information, radio signals/channels, etc., using the one or

more processors

102 and 202. The one or

more transceivers

106 and 206 may convert the user data, control information, radio signals/channels, etc., processed using the one or

more processors

102 and 202 from the base band signals into the RF band signals. To this end, the one or

more transceivers

106 and 206 may include (analog) oscillators and/or filters. For example, the one or

more transceivers

106 and 206 can up-convert OFDM baseband signals to OFDM signals by their (analog) oscillators and/or filters under the control of the one or

more processors

102 and 202 and transmit the up-converted OFDM signals at the carrier frequency. The one or

more transceivers

106 and 206 may receive OFDM signals at a carrier frequency and down-convert the OFDM signals into OFDM baseband signals by their (analog) oscillators and/or filters under the control of the one or

more processors

102 and 202.

Although not shown in FIG. 2, the

wireless devices

100 and 200 may further include additional components. The additional components 140 may be variously configured according to types of the

wireless devices

100 and 200. For example, the additional components 140 may include at least one of a power unit/battery, an Input/Output (I/O) device (e.g., audio I/O port, video I/O port), a driving device, and a computing device. The additional components 140 may be coupled to the one or

more processors

102 and 202 via various technologies, such as a wired or wireless connection.

In the implementations of the present disclosure, a UE may operate as a transmitting device in Uplink (UL) and as a receiving device in Downlink (DL). In the implementations of the present disclosure, a BS may operate as a receiving device in UL and as a transmitting device in DL. Hereinafter, for convenience of description, it is mainly assumed that the first wireless device 100 acts as the UE, and the second wireless device 200 acts as the BS. For example, the processor(s) 102 connected to, mounted on or launched in the first wireless device 100 may be adapted to perform the UE behavior according to an implementation of the present disclosure or control the transceiver(s) 106 to perform the UE behavior according to an implementation of the present disclosure. The processor(s) 202 connected to, mounted on or launched in the second wireless device 200 may be adapted to perform the BS behavior according to an implementation of the present disclosure or control the transceiver(s) 206 to perform the BS behavior according to an implementation of the present disclosure.

In the present disclosure, a BS is also referred to as a node B (NB), an eNode B (eNB), or a gNB.

Referring to FIG. 3, a UE 100 may correspond to the first wireless device 100 of FIG. 2.

A UE 100 includes a processor 102, a memory 104, a transceiver 106, one or more antennas 108, a power management module 141, a battery 142, a display 143, a keypad 144, a Subscriber Identification Module (SIM) card 145, a speaker 146, and a microphone 147.

The processor 102 may be adapted to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. The processor 102 may be adapted to control one or more other components of the UE 100 to implement the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. Layers of the radio interface protocol may be implemented in the processor 102. The processor 102 may include ASIC, other chipset, logic circuit and/or data processing device. The processor 102 may be an application processor. The processor 102 may include at least one of DSP, CPU, GPU, a modem (modulator and demodulator). An example of the processor 102 may be found in SNAPDRAGON^TM series of processors made by Qualcomm^®, EXYNOS^TM series of processors made by Samsung^®, A series of processors made by Apple^®, HELIO^TM series of processors made by MediaTek^®, ATOM^TM series of processors made by Intel^® or a corresponding next generation processor.

The memory 104 is operatively coupled with the processor 102 and stores a variety of information to operate the processor 102. The memory 104 may include ROM, RAM, flash memory, memory card, storage medium and/or other storage device. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, suggestions, methods and/or operational flowcharts disclosed in the present disclosure. The modules can be stored in the memory 104 and executed by the processor 102. The memory 104 can be implemented within the processor 102 or external to the processor 102 in which case those can be communicatively coupled to the processor 102 via various means as is known in the art.

The transceiver 106 is operatively coupled with the processor 102, and transmits and/or receives a radio signal. The transceiver 106 includes a transmitter and a receiver. The transceiver 106 may include baseband circuitry to process radio frequency signals. The transceiver 106 controls the one or more antennas 108 to transmit and/or receive a radio signal.

The power management module 141 manages power for the processor 102 and/or the transceiver 106. The battery 142 supplies power to the power management module 141.

The display 143 outputs results processed by the processor 102. The keypad 144 receives inputs to be used by the processor 102. The keypad 144 may be shown on the display 143.

The SIM card 145 is an　integrated circuit　that is intended to　securely store the　International Mobile Subscriber Identity　(IMSI) number and its related　key, which are used to identify and authenticate subscribers on　mobile telephony　devices (such as　mobile phones　and　computers). It is also possible to store contact information on many SIM cards.

The speaker 146 outputs sound-related results processed by the processor 102. The microphone 147 receives sound-related inputs to be used by the processor 102.

The 5G system (5GS) architecture consists of the following network functions (NF).

- Authentication Server Function (AUSF)

- Access and Mobility Management Function (AMF)

- Data Network (DN), e.g., operator services, Internet access or 3rd party services

- Unstructured Data Storage Function (UDSF)

- Network Exposure Function (NEF)

- Intermediate NEF (I-NEF)

- Network Repository Function (NRF)

- Network Slice Selection Function (NSSF)

- Policy Control Function (PCF)

- Session Management Function (SMF)

- Unified Data Management (UDM)

- Unified Data Repository (UDR)

- User Plane Function (UPF)

- UE radio Capability Management Function (UCMF)

- Application Function (AF)

- User Equipment (UE)

- (Radio) Access Network ((R)AN)

- 5G-Equipment Identity Register (5G-EIR)

- Network Data Analytics Function (NWDAF)

- CHarging Function (CHF)

Furthermore, the following network functions may be considered.

- Non-3GPP InterWorking Function (N3IWF)

- Trusted Non-3GPP Gateway Function (TNGF)

- Wireline Access Gateway Function (W-AGF)

FIG. 4 depicts the 5G system architecture in the non-roaming case, using the reference point representation showing how various network functions interact with each other.

In FIG. 4, for the sake of clarity of the point-to-point diagrams, the UDSF, NEF and NRF have not been depicted. However, all depicted Network Functions can interact with the UDSF, UDR, NEF and NRF as necessary.

For clarity, the UDR and its connections with other NFs, e.g., PCF, are not depicted in FIG. 4. For clarity, the NWDAF and its connections with other NFs, e.g., PCF, are not depicted in FIG. 4.

The 5G system architecture contains the following reference points:

- N1: Reference point between the UE and the AMF.

- N2: Reference point between the (R)AN and the AMF.

- N3: Reference point between the (R)AN and the UPF.

- N4: Reference point between the SMF and the UPF.

- N6: Reference point between the UPF and a Data Network.

- N9: Reference point between two UPFs.

The following reference points show the interactions that exist between the NF services in the NFs.

- N5: Reference point between the PCF and an AF.

- N7: Reference point between the SMF and the PCF.

- N8: Reference point between the UDM and the AMF.

- N10: Reference point between the UDM and the SMF.

- N11: Reference point between the AMF and the SMF.

- N12: Reference point between the AMF and the AUSF.

- N13: Reference point between the UDM and the AUSF.

- N14: Reference point between two AMFs.

- N15: Reference point between the PCF and the AMF in the case of non-roaming scenario, PCF in the visited network and AMF in the case of roaming scenario.

- N16: Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF in the home network).

- N22: Reference point between the AMF and the NSSF.

In some cases, a couple of NFs may need to be associated with each other to serve a UE.

A registration procedure is described. Section 4.2.2.2 of 3GPP TS 23.502 V16.3.0 (2019-12) can be referred.

A UE needs to register with the network to get authorized to receive services, to enable mobility tracking and to enable reachability. The UE initiates the registration procedure using one of the following registration types:

- Initial registration to the 5GS; or

- Mobility registration update; or

- Periodic registration update; or

- Emergency registration.

The general registration procedure in FIGS. 5 and 6 applies on all these registration procedures, but the periodic registration update need not include all parameters that are used in other registration cases.

The general registration procedure in FIGS. 5 and 6 is also used for the case of registration in 3GPP access when the UE is already registered in a non-3GPP access, and vice versa. Registration in 3GPP access when the UE is already registered in a non-3GPP access scenario may require an AMF change.

First, procedures of FIG. 6 are described.

(1) Step 1: The UE transmits a Registration Request message to the (R)AN. The Registration Request message corresponds to AN message.

The Registration Request message may include AN parameters. In the case of NG-RAN, the AN parameters include, e.g., 5G SAE temporary mobile subscriber identity (5G-S-TMSI) or globally unique AMF ID (GUAMI), the selected public land mobile network (PLMN) ID (or PLMN ID and network identifier (NID)) and Requested network slice selection assistance information (NSSAI). The AN parameters also include establishment cause. The establishment cause provides the reason for requesting the establishment of an RRC connection. Whether and how the UE includes the Requested NSSAI as part of the AN parameters is dependent on the value of the access stratum connection establishment NSSAI inclusion mode parameter.

The Registration Request message may include a registration type. The registration type indicates if the UE wants to perform an initial registration (i.e., the UE is in RM-DEREGISTERED state), a mobility registration update (i.e., the UE is in RM-REGISTERED state and initiates a registration procedure due to mobility or due to the UE needs to update its capabilities or protocol parameters, or to request a change of the set of network slices it is allowed to use), a periodic registration update (i.e., the UE is in RM-REGISTERED state and initiates a registration procedure due to the periodic registration update timer expiry) or an emergency registration (i.e., the UE is in limited service state).

When the UE is performing an initial registration, the UE shall indicate its UE identity in the Registration Request message as follows, listed in decreasing order of preference:

i) a 5G globally unique temporary identifier (5G-GUTI) mapped from an evolved packet system (EPS) GUTI, if the UE has a valid EPS GUTI.

ii) a native 5G-GUTI assigned by the PLMN to which the UE is attempting to register, if available;

iii) a native 5G-GUTI assigned by an equivalent PLMN to the PLMN to which the UE is attempting to register, if available;

iv) a native 5G-GUTI assigned by any other PLMN, if available.

v) Otherwise, the UE shall include its subscriber concealed identifier (SUCI) in the Registration Request message.

When the UE performing an initial registration has both a valid EPS GUTI and a native 5G-GUTI, the UE shall also indicate the native 5G-GUTI as additional GUTI. If more than one native 5G-GUTIs are available, the UE shall select the 5G-GUTI in decreasing order of preference among items (ii)-(iv) in the list above.

When the UE is performing an initial registration with a native 5G-GUTI, then the UE shall indicate the related GUAMI information in the AN parameters. When the UE is performing an initial registration with its SUCI, the UE shall not indicate any GUAMI information in the AN parameters.

For an emergency registration, the SUCI shall be included if the UE does not have a valid 5G-GUTI available; the permanent equipment identifier (PEI) shall be included when the UE has no subscriber permanent identifier (SUPI) and no valid 5G-GUTI. In other cases, the 5G-GUTI is included and it indicates the last serving AMF.

The Registration Request message may also include security parameters, PDU Session Status, etc. The security parameters are used for authentication and integrity protection. The PDU Session Status indicates the previously established PDU sessions in the UE. When the UE is connected to the two AMFs belonging to different PLMN via 3GPP access and non-3GPP access then the PDU Session status indicates the established PDU Session of the current PLMN in the UE.

(2) Step 2: The (R)AN selects an AMF.

If a 5G-S-TMSI or GUAMI is not included or the 5G-S-TMSI or GUAMI does not indicate a valid AMF, the (R)AN, based on (R)AT and requested NSSAI, if available, selects an AMF.

If UE is in CM-CONNECTED state, the (R)AN can forward the Registration Request message to the AMF based on the N2 connection of the UE.

If the (R)AN cannot select an appropriate AMF, it forwards the Registration Request message to an AMF which has been configured, in the (R)AN, to perform AMF selection.

(3) Step 3: The (R)AN transmits a Registration Request message to the new AMF. The Registration Request message corresponds to N2 message.

The Registration Request message may include whole information and/or a part of information included in the Registration Request message received from the UE which is described in step 1.

The Registration Request message may include N2 parameters. When NG-RAN is used, the N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell identity related to the cell in which the UE is camping, UE context request which indicates that a UE context including security information needs to be setup at the NG-RAN. When NG-RAN is used, the N2 parameters shall also include the establishment cause.

If the Registration type indicated by the UE is Periodic Registration Update, then steps 4 to 19 may be omitted.

(4) Step 4: If the UE's 5G-GUTI was included in the Registration Request message and the serving AMF has changed since last registration procedure, the new AMF may invoke the Namf_Communication_UEContextTransfer service operation on the old AMF including the complete registration request non-access stratum (NAS) message to request the UE's SUPI and UE context.

(5) Step 5: The Old AMF may respond to the new AMF for the Namf_Communication_UEContextTransfer invocation by including the UE's SUPI and UE context.

(6) Step 6: If the SUCI is not provided by the UE nor retrieved from the old AMF, the identity request procedure may be initiated by the new AMF sending the Identity Request message to the UE requesting the SUCI.

(7) Step 7: The UE may respond with an Identity Response message including the SUCI. The UE derives the SUCI by using the provisioned public key of the home PLMN (HPLMN).

(8) Step 8: The new AMF may decide to initiate UE authentication by invoking an AUSF. In that case, the new AMF selects an AUSF based on SUPI or SUCI.

(9) Step 9: Authentication/security may be established by the UE, new AMF, AUSF and/or UDM.

(10) Step 10: If the AMF has changed, the new AMF may notify the old AMF that the registration of the UE in the new AMF is completed by invoking the Namf_Communication_RegistrationCompleteNotify service operation. If the authentication/security procedure fails, then the registration shall be rejected, and the new AMF may invoke the Namf_Communication_RegistrationCompleteNotify service operation with a reject indication reason code towards the old AMF. The old AMF may continue as if the UE context transfer service operation was never received.

(11) Step 11: If the PEI was not provided by the UE nor retrieved from the old AMF, the Identity Request procedure may be initiated by the new AMF sending an Identity Request message to the UE to retrieve the PEI. The PEI shall be transferred encrypted unless the UE performs emergency registration and cannot be authenticated.

(12) Step 12: Optionally, the new AMF may initiate ME identity check by invoking the N5g-eir_EquipmentIdentityCheck_Get service operation.

Now, procedures of FIG. 6, which follow the procedures of FIG. 5, are described.

(13) Step 13: If step 14 below is to be performed, the new AMF, based on the SUPI, may select a UDM, then UDM may select a UDR instance.

(14) Step 14: The new AMF may register with the UDM.

(15) Step 15: The new AMF may select a PCF.

(16) Step 16: The new AMF may optionally perform an AM Policy Association Establishment/Modification.

(17) Step 17: The new AMF may transmit Update/Release SM Context message (e.g., Nsmf_PDUSession_UpdateSMContext and/or Nsmf_PDUSession_ReleaseSMContext) to the SMF.

(18) Step 18: If the new AMF and the old AMF are in the same PLMN, the new AMF may send a UE Context Modification Request to the N3IWF/TNGF/W-AGF.

(19) Step 19: The N3IWF/TNGF/W-AGF may send a UE Context Modification Response to the new AMF.

(20) Step 20: After the new AMF receives the response message from the N3IWF/TNGF/W-AGF in step 19, the new AMF may register with the UDM.

(21) Step 21: The new AMF transmits a Registration Accept message to the UE.

The new AMF sends a Registration Accept message to the UE indicating that the Registration Request has been accepted. 5G-GUTI is included if the new AMF allocates a new 5G-GUTI. If the UE is already in RM-REGISTERED state via another access in the same PLMN, the UE shall use the 5G-GUTI received in the Registration Accept message for both registrations. If no 5G-GUTI is included in the Registration Accept message, then the UE uses the 5G-GUTI assigned for the existing registration also for the new registration. If the new AMF allocates a new registration area, it shall send the registration area to the UE via Registration Accept message. If there is no registration area included in the Registration Accept message, the UE shall consider the old registration area as valid. Mobility Restrictions is included in case mobility restrictions applies for the UE and registration type is not emergency registration. The new AMF indicates the established PDU sessions to the UE in the PDU Session status. The UE removes locally any internal resources related to PDU sessions that are not marked as established in the received PDU Session status. When the UE is connected to the two AMFs belonging to different PLMN via 3GPP access and non-3GPP access then the UE removes locally any internal resources related to the PDU session of the current PLMN that are not marked as established in received PDU Session status. If the PDU Session status information was in the Registration Request message, the new AMF shall indicate the PDU Session status to the UE.

The Allowed NSSAI provided in the Registration Accept message is valid in the registration area and it applies for all the PLMNs which have their tracking areas included in the registration area. The Mapping Of Allowed NSSAI is the mapping of each S-NSSAI of the Allowed NSSAI to the HPLMN S-NSSAIs. The Mapping Of Configured NSSAI is the mapping of each S-NSSAI of the Configured NSSAI for the serving PLMN to the HPLMN S-NSSAIs.

Furthermore, optionally the new AMF performs a UE Policy Association Establishment.

(22) Step 22: The UE may send a Registration Complete message to the new AMF when it has successfully updated itself.

The UE may send a Registration Complete message to the new AMF to acknowledge if a new 5G-GUTI was assigned.

(23) Step 23: For registration over 3GPP Access, if the new AMF does not release the signaling connection, the new AMF may send the RRC Inactive Assistance Information to the NG-RAN. For registration over non-3GPP Access, if the UE is also in CM-CONNECTED state on 3GPP access, the new AMF may send the RRC Inactive Assistance Information to the NG-RAN.

(24) Step 24: The new AMF may perform information update towards the UDM.

(25) Step 25: The UE may execute Network Slice-Specific Authentication and Authorization procedure.

Steering of Roaming (SOR): A technique whereby a roaming UE is encouraged to roam to a preferred roamed-to-network indicated by the HPLMN.

Steering of Roaming application function (SOR-AF): An application function that can provide UDM with one of the following:

a) one or more of the following:

- list of preferred PLMN/access technology combinations;

- SOR-CMCI, together with the "Store SOR-CMCI in ME" indicator if applicable;

- SOR-SNPN-SI;

b) a secured packet, together with the indicator, if applicable, that "the list of preferred PLMN/access technology combinations is not included in the secured packet"; or

c) neither of a) or b),

generated dynamically based on operator specific data analytics solutions.

Steering of Roaming information: This consists of the following HPLMN or subscribed SNPN protected information (see 3GPP TS 33.501 V18.0.0):

a) the following indicators, of whether:

- the UDM requests an acknowledgement from the UE for successful reception of the steering of roaming information.

- the UDM requests the UE to store the SOR-CMCI in the ME, which is provided along with the SOR-CMCI in plain text; and

b) one of the following:

1) one or more of the following:

- list of preferred PLMN/access technology combinations with an indication that it is included;

- SOR-CMCI; or

- SOR-SNPN-SI;

2) a secured packet with an indication that it is included;

3) the HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided'; or

4) the subscribed SNPN or HPLMN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'.

Steering of roaming connected mode control information (SOR-CMCI): HPLMN information to control the timing for a UE in connected mode to move to idle mode in order to perform steering of roaming.

Steering of roaming SNPN selection information (SOR-SNPN-SI): Provisioning information for SNPN selection consisting of:

a) the credentials holder controlled prioritized list of preferred SNPNs;

b) the credentials holder controlled prioritized list of Group ID for Network Selection (GIN)s; or

c) both of the above.

C.0 Control plane solution for steering of roaming in 5GS is explained.

Requirements for 5G steering of roaming over the control plane are explained.

The UE supporting N1 mode may support the control plane solution for steering of roaming in 5GS. If the HPLMN or subscribed SNPN supports and wants to use the control plane solution for steering of roaming in 5GS, then the HPLMN or subscribed SNPN may provide the steering of roaming information to the UE using the control plane mechanism defined in the following.

The VPLMN may transparently relay the steering of roaming information received from the HPLMN to the UE. The UE may be able to detect whether the VPLMN removed the steering of roaming information during the initial registration procedure in the VPLMN. The UE may be able to detect whether the VPLMN altered the steering of roaming information. If the UE detects that the VPLMN altered or removed the steering of roaming information then the UE may consider the current VPLMN as the lowest priority PLMN and perform PLMN selection as defined in this ann the following examples.

The non-subscribed SNPN may transparently relay the steering of roaming information received from the HPLMN or subscribed SNPN to the UE. The UE may be able to detect whether the non-subscribed SNPN removed the steering of roaming information during the initial registration procedure in the non-subscribed SNPN. The UE may be able to detect whether the non-subcribed SNPN altered the steering of roaming information. If the UE detects that the non-subscribed SNPN altered or removed the steering of roaming information then the UE may consider the current SNPN as the lowest priority SNPN and perform SNPN selection as defined in the following.

C.1 General

C.1.1 Steering of roaming over the control plane in a PLMN

The purpose of the control plane solution for steering of roaming in 5GS procedure in a PLMN is to allow the HPLMN to update one or more of the following via NAS signalling:

a) the "Operator Controlled PLMN Selector with Access Technology" list in the UE by providing the HPLMN protected list of preferred PLMN/access technology combinations or a secured packet;

b) the SOR-CMCI; and

c) the SOR-SNPN-SI associated with the selected PLMN subscription in the ME.

If the selected PLMN is a VPLMN, the HPLMN can provide the steering of roaming information to the UE using the control plane mechanism during and after registration. If the selected PLMN is the HPLMN, the HPLMN can provide the steering of roaming information to the UE using the control plane mechanism after registration only. The HPLMN updates the "Operator Controlled PLMN Selector with Access Technology" based on the operator policies, which can be based on the registered VPLMN, the location of the UE, etc.

The HPLMN can configure their subscribed UE's USIM to indicate that the UE is expected to receive the steering of roaming information due to initial registration in 5GS in a VPLMN. At the same time the HPLMN will mark the UE is expected to receive the steering of roaming information due to initial registration in 5GS in a VPLMN, in the subscription information in the UDM. In this case, it is mandatory for the HPLMN to provide the steering of roaming information to the UE during initial registration in a VPLMN. Otherwise if such configuration is not provided in the USIM, it is optional for the HPLMN to provide the steering of roaming information to the UE during initial registration (based on operator policy). The HPLMN can provide the steering of roaming information to the UE during the registration procedure for mobility and periodic registration update (see 3GPP TS 24.501 V18.0.0) and initial registration procedure for emergency services. In addition, the HPLMN can request the UE to provide an acknowledgement of successful reception of the steering of roaming information.

As the HPLMN needs to consider certain criteria including the number of customers distributed through multiple VPLMNs in the same country or region, the list of the preferred PLMN/access technology combinations is not necessarily the same at all times and for all users. The list of the preferred PLMN/access technology combinations needs to be dynamically generated, e.g. generated on demand, by a dedicated steering of roaming application function (SOR-AF) providing operator specific data analytics solutions.

The steering of roaming connected mode control information (SOR-CMCI) enables the HPLMN to control the timing of a UE in 5GS connected mode to move to idle mode to perform the steering of roaming. If the UE selects a cell of any access technology other than NG-RAN, the SOR procedure is terminated (see clause C.4.2). The UE may support the SOR-CMCI. The support and use of SOR-CMCI by the HPLMN is based on the HPLMN's operator policy.

The following requirements are applicable for the SOR-CMCI:

- The HPLMN may configure SOR-CMCI in the UE and may also send SOR-CMCI over N1 NAS signalling. The SOR-CMCI received over N1 NAS signalling has precedence over the SOR-CMCI configured in the UE.

- The UE may indicate ME's support for SOR-CMCI to the HPLMN.

- While performing SOR, the UE may consider the list of preferred PLMN/access technology combinations or secured packet received in the SOR information together with the available SOR-CMCI.

- The HPLMN may provision the SOR-CMCI in the UE over N1 NAS signalling. The UE may store the configured SOR-CMCI in the non-volatile memory of the ME or in the USIM as described in clause C.4.

The following requirements are applicable for the SOR-SNPN-SI:

- If the UE supports access to an SNPN using credentials from a credentials holder, the UE may indicate ME's support for SOR-SNPN-SI to the HPLMN.

In order to support various deployment scenarios, the UDM may support:

- obtaining a list of preferred PLMN/access technology combinations, and SOR-CMCI, if any (if supported by the UDM and required by the HPLMN), or a secured packet which is or becomes available in the UDM (i.e. retrieved from the UDR);

- obtaining a list of preferred PLMN/access technology combinations and SOR-CMCI, if any (if supported by the UDM and required by the HPLMN), or a secured packet from the SOR-AF; or

- both of the above.

The HPLMN policy for the SOR-AF invocation can be present in the UDM only if the UDM supports obtaining a list of preferred PLMN/access technology combinations and SOR-CMCI, if any, or a secured packet from the SOR-AF.

The UE maintains a list of "PLMNs where registration was aborted due to SOR". If the UE receives steering of roaming information in the REGISTRATION ACCEPT or DL NAS TRANSPORT message and the security check to verify that the steering of roaming information is provided by HPLMN is successful, the UE may remove the current selected PLMN from the list of "PLMNs where registration was aborted due to SOR". The UE may delete the list of "PLMNs where registration was aborted due to SOR" when the MS is switched off, the USIM is removed or after a UE implementation dependent time.

If:

- the UE's USIM is configured to indicate that the UE may expect to receive the steering of roaming information during initial registration procedure but did not receive it or security check on the steering of roaming information fails;

- the current chosen VPLMN is not contained in the list of "PLMNs where registration was aborted due to SOR";

- the current chosen VPLMN is not part of "User Controlled PLMN Selector with Access Technology" list; and

- the UE is not in manual mode of operation;

then the UE will perform PLMN selection with the current VPLMN considered as lowest priority.

It is mandatory for the VPLMN to transparently forward to the UE the steering of roaming information received from HPLMN and to transparently forward to the HPLMN the acknowledgement of successful reception of the steering of roaming information received from UE, both while the UE is trying to register onto the VPLMN as described in clause C.2, and after the UE has registered onto the VPLMN as described in clause C.3 and C.4.3.

If the last received steering of roaming information contains the list of preferred PLMN/access technology combinations then the ME may not delete the "Operator Controlled PLMN Selector with Access Technology" list stored in the non-volatile memory of the ME when the UE is switched off.

The "Operator Controlled PLMN Selector with Access Technology" list may be stored in the non-volatile memory of the ME together with the SUPI from the USIM. The ME may delete the "Operator Controlled PLMN Selector with Access Technology" list stored in the ME when a new USIM is inserted.

The procedure in this annex for steering of UE in VPLMN can be initiated by the network while the UE is trying to register onto the VPLMN as described in clause C.2, or after the UE has registered onto the HPLMN or the VPLMN as described in clause C.3, C.7 and C.4.3.

C.1.2 Steering of roaming over the control plane in an SNPN

The purpose of the control plane solution for steering of roaming in 5GS procedure in an SNPN is to allow the HPLMN or subscribed SNPN to update one or more of the following via NAS signalling:

a) the SOR-SNPN-SI associated with the selected entry of "list of subscriber data" or the selected PLMN subscription in the ME, for a UE which supports access to an SNPN using credentials from a credential holder; and

b) the SOR-CMCI.

The control plane solution for steering of roaming in 5GS procedure in an SNPN can also be used by the HPLMN to update the "Operator Controlled PLMN Selector with Access Technology" list in the UE by providing the HPLMN protected list of preferred PLMN/access technology combinations or a secured packet via NAS signalling.

The HPLMN or subscribed SNPN can provide the steering of roaming information to the UE using the control plane mechanism during and after registration. The HPLMN or subscribed SNPN updates the SOR-SNPN-SI based on the HPLMN or subscribed SNPN policies, which can be based on the registered SNPN, the location of the UE, etc. The control plane solution for steering of roaming in 5GS procedure in an SNPN is not applicable for credentials holder with AAA server.

If the UE supports access to an SNPN using credentials from a credentials holder:

a) the UE may indicate ME's support for SOR-SNPN-SI when registering in a subscribed SNPN or in the HPLMN; and

b) the UE may indicate ME's support for SOR-SNPN-SI when sending an SOR transparent container including a UE acknowledgement in a PLMN.

When the UE indicates ME's support for SOR-SNPN-SI in the 5GMM capability in initial registration or emergency registration or when ME's support for SOR-SNPN-SI changes in mobility registration update, the AMF may inform the UDM.

The HPLMN or subscribed SNPN can configure their subscribed UEs' SNPN configuration parameters associated with the PLMN subscription or the selected entry of the "list of subscriber data", respectively, to expect to receive the steering of roaming information due to initial registration in a non-subscribed SNPN. At the same time the HPLMN or subscribed SNPN will mark the UE as expecting to receive the steering of roaming information due to initial registration in a non-subscribed SNPN, in the subscription information in the UDM. In this case, it is mandatory for the HPLMN or subscribed SNPN to provide the steering of roaming information to the UE during initial registration in a non-subscribed SNPN. Otherwise if such configuration is not provided in the ME, it is optional for the HPLMN or subscribed SNPN to provide the steering of roaming information to the UE during initial registration (based on HPLMN or subscribed SNPN policy). The HPLMN or subscribed SNPN can provide the steering of roaming information to the UE during the registration procedure for mobility and periodic registration update (see 3GPP TS 24.501 ) and initial registration procedure for emergency services. In addition, the HPLMN or subscribed SNPN can request the UE to provide an acknowledgement of successful reception of the steering of roaming information.

As the HPLMN or subscribed SNPN needs to consider certain criteria including the number of customers distributed through multiple SNPNs in the same country or region, the SOR-SNPN-SI is not necessarily the same at all times and for all users.

The steering of roaming connected mode control information (SOR-CMCI) enables the HPLMN or subscribed SNPN to control the timing of a UE in connected mode to move to idle mode, if the UE decides to perform SNPN selection upon receiving the steering of roaming information. The UE may support the SOR-CMCI. The support and use of SOR-CMCI by the HPLMN or subscribed SNPN is based on the HPLMN or subscribed SNPN policy.

The following requirements are applicable for the SOR-CMCI:

- The HPLMN or subscribed SNPN may configure SOR-CMCI in the UE and may also send SOR-CMCI over N1 NAS signalling. The SOR-CMCI received over N1 NAS signalling has precedence over the SOR-CMCI configured in the UE.

- The UE may indicate ME's support for SOR-CMCI to the HPLMN or subscribed SNPN.

- While performing SOR, the UE may consider the SOR-SNPN-SI received in the SOR information together with the available SOR-CMCI.

- The HPLMN or subscribed SNPN may provision the SOR-CMCI in the UE over N1 NAS signalling. The UE may store the configured SOR-CMCI in the non-volatile memory of the ME or in the USIM as described in clause C.4.

In order to support various deployment scenarios, the UDM may support:

- obtaining the SOR-SNPN-SI which is or becomes available in the UDM (i.e. retrieved from the UDR);

- obtaining the SOR-SNPN-SI from the SOR-AF; or

- both of the above.

The HPLMN or subscribed SNPN policy for the SOR-AF invocation can be present in the UDM only if the UDM supports obtaining the SOR-SNPN-SI from the SOR-AF.

The UDM discards any SOR-SNPN-SI obtained from the SOR-AF or which is or becomes available in the UDM (i.e. retrieved from the UDR), either during registration (as specified in annex C.5) or after registration (as specified in annex C.6), when the UDM cannot successfully forward the SOR information to the AMF (e.g. in case the UDM receives the response from the SOR-AF with the SOR-SNPN-SI after the expiration of the HPLMN or subscribed SNPN specific timer, or if there is no AMF registered for the UE).

The UE maintains a list of "SNPNs where registration was aborted due to SOR" per entry of the "list of subscriber data" or the PLMN subscription. If the UE receives steering of roaming information in the REGISTRATION ACCEPT or DL NAS TRANSPORT message in an SNPN and the security check to verify that the steering of roaming information is provided by the HPLMN or subscribed SNPN is successful, the UE may remove the current selected SNPN from the list of "SNPNs where registration was aborted due to SOR" for the selected entry of the "list of subscriber data" or the selected PLMN subscription. The UE may delete the list of "SNPNs where registration was aborted due to SOR" when the selected entry of the "list of subscriber data" is updated or the UICC containind the USIM is removed.

If:

- the UE's ME is configured to indicate that the UE may expect to receive the steering of roaming information during initial registration procedure for the selected entry of the "list of subscriber data" or the selected PLMN subscription but did not receive it or security check on the steering of roaming information fails;

- the current chosen non-subscribed SNPN is not contained in the list of "SNPNs where registration was aborted due to SOR" for the selected entry of the "list of subscriber data" or the selected PLMN subscription;

- the current chosen non-subscribed SNPN is not part of the user controlled prioritized list of preferred SNPNs for the selected entry of the "list of subscriber data" or the selected PLMN subscription; and

- the UE is not in manual mode of operation;

then the UE will perform SNPN selection with the current SNPN considered as lowest priority.

It is mandatory for the non-subscribed SNPN to transparently forward to the UE the steering of roaming information received from the HPLMN or subscribed SNPN and to transparently forward to the HPLMN or subscribed SNPN the acknowledgement of successful reception of the steering of roaming information received from the UE, both while the UE is trying to register onto the non-subscribed SNPN as described in clause C.5, and after the UE has registered onto the non-subscribed SNPN as described in clause C.6.

The ME may delete the SOR-SNPN-SI stored in the ME when the subscriber identifier, the SNPN identity of the subscribed SNPN, or both, of the selected entry of the "list of subscriber data" are updated or the UICC containing the USIM is removed.

The procedure in this annex for steering of UE in an SNPN can be initiated by the network while the UE is trying to register onto a non-subscribed SNPN as described in clause C.5, or after the UE has registered onto the subscribed SNPN or a non-subscribed SNPN as described in clause C.6 and C.8.

C.4.3 Stage-2 flow for providing UE with SOR-CMCI in HPLMN, VPLMN, subscribed SNPN or non-subscribed SNPN after registration

The stage-2 flow for providing UE with SOR-CMCI in HPLMN, VPLMN, subscribed SNPN or non-subscribed SNPN after registration is indicated in FIG. 7, when the ME supports the SOR-CMCI. The selected PLMN or SNPN can be the HPLMN, a VPLMN, the subscribed SNPN or a non-subscribed SNPN. The AMF is located in the selected PLMN or SNPN. The UDM is located in the HPLMN or the subscribed SNPN.

In this procedure, the SOR-CMCI is sent without the list of preferred PLMN/access technology combinations and the SOR-SNPN-SI. In this procedure, the SOR-CMCI is sent in plain text or is sent within the secured packet.

NOTE　0: When the UE is registered in a non-subscribed SNPN, the SOR-CMCI can be provided in a secured packet only if the UE is using a PLMN subscription to access the non-subscribed SNPN.

NOTE　1: The SOR-AF can determine that the ME supports the SOR-CMCI if the Nsoraf_SoR_Info service operation has returned the "ME support of SOR-CMCI" indicator. The UDM can determine that the ME supports the SOR-CMCI if the "ME support of SOR-CMCI" indicator is stored for the UE. How the SOR-AF determines that the USIM for the indicated SUPI supports SOR-CMCI is implementation specific.

NOTE　2: The secured packet provided by the SOR-AF can include SOR-CMCI only if the SOR-AF has determined that the ME supports the SOR-CMCI and the USIM of the indicated SUPI supports SOR-CMCI. Otherwise if only the "ME support of SOR-CMCI" indicator is stored for the UE, then SOR-CMCI, if any, cannot be included in the secured packet.

The procedure is triggered:

- If the UDM supports obtaining the parameters of the list of preferred PLMN/access technology combinations, the SOR-SNPN-SI, the SOR-CMCI, and the "Store SOR-CMCI in ME" indicator, if any, or a secured packet from the SOR-AF, the HPLMN or subscribed SNPN policy for the SOR-AF invocation is present in the UDM and the SOR-AF provides the UDM with the SOR-CMCI for a UE identified by SUPI; or

- When the SOR-CMCI becomes available in the UDM (i.e., retrieved from the UDR).

The following drawings are intended to illustrate specific embodiments of the present disclosure. The designations of specific devices or the designations of specific signals/messages/fields shown in the drawings are for illustrative purposes only, and the technical features of the present specification are not limited to the specific designations used in the drawings below.

For the steps below, security protection is described in 3GPP　TS　33.501.

1) The SOR-AF to the UDM: Nudm_ParameterProvision_Update request is sent to the UDM to trigger the update of the UE with the SOR-CMCI (in plain text or secured packet). In case of providing SOR-CMCI in plain text, include the "Store SOR-CMCI in ME" indicator, if applicable. In case of providing SOR-CMCI in a secured packet, include an indication that "the list of preferred PLMN/access technology combinations is not included in the secured packet".

2) The UDM to the AMF: The UDM notifies the changes of the user profile to the affected AMF by the means of invoking Nudm_SDM_Notification service operation. The Nudm_SDM_Notification service operation contains the steering of roaming information that needs to be delivered transparently to the UE over NAS within the Access and Mobility Subscription data. If the HPLMN or subscribed SNPN decided that the UE is to acknowledge successful security check of the received steering of roaming information, the Nudm_SDM_Notification service operation also contains an indication that the UDM requests an acknowledgement from the UE as part of the steering of roaming information. The UDM:

- upon receiving the SOR-CMCI (in plain text), shall:

i) if the UE is registered in the HPLMN or a VPLMN, include the SOR-CMCI, the "Store SOR-CMCI in ME" indicator, if any, and the HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided';

ii) if the UE is registered in a non-subcribed SNPN, include the SOR-CMCI, the "Store SOR-CMCI in ME" indicator, if any, and the HPLMN or subscribed SNPN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'; and

iii) if the UE is registered in a subcribed SNPN and the AMF has reported to the UDM that the UE supports SOR-SNPN-SI, include the SOR-CMCI, the "Store SOR-CMCI in ME" indicator, if any, and the HPLMN or subscribed SNPN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'; or

- upon receiving the SOR-CMCI in secured packet, shall include the secured packet into the steering of roaming information;

NOTE　3: The UDM considers "the list of preferred PLMN/access technology combinations is not included in the secured packet" received together with the secured packet from the SOR-AF to indicate that the UE is not expected to perform SOR based on the associated steering of roaming information sent to the UE. However, the SOR-CMCI included in the secured packet can be applied by the UE if the UE has one or more Tsor-cm timers running as described in C.4.2.

NOTE　4: The UDM cannot provide the SOR-CMCI, if any, to the AMF which does not support receiving SoR transparent container (see 3GPP　TS　29.503).

3) The AMF to the UE: the AMF sends a DL NAS TRANSPORT message to the served UE. The AMF includes in the DL NAS TRANSPORT message the steering of roaming information received from the UDM.

4) Upon receiving the steering of roaming information containing the SOR-CMCI and the HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided' or the HPLMN or subscribed SNPN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided', or the secured packet, the UE shall perform a security check on the steering of roaming information included in the DL NAS TRANSPORT message to verify that the steering of roaming information is provided by HPLMN or subscribed SNPN, and:

a) if the security check is successful, the UE shall store the SOR-CMCI according to clause　C.4.1. If the UE has one or more Tsor-cm timers running, the UE shall apply the received SOR-CMCI as described in C.4.2.

If the steering of roaming information contains a secured packet and the UDM has requested an acknowledgement from the UE in the DL NAS TRANSPORT message, the UE sends an UL NAS TRANSPORT message to the serving AMF with an SOR transparent container including the UE acknowledgement and the UE shall set the "ME support of SOR-CMCI" indicator to "supported" only after the ME receives UICC responses indicating that the UICC has received the secured packet successfully. Otherwise, if the UDM has requested an acknowledgement from the UE in the DL NAS TRANSPORT message, the UE sends an UL NAS TRANSPORT message to the serving AMF with an SOR transparent container including the UE acknowledgement and the UE shall set the "ME support of SOR-CMCI" indicator to "supported". Additionally, if the UE supports access to an SNPN using credentials from a credentials holder and the UE is in a PLMN, the UE may set the "ME support of SOR-SNPN-SI" indicator to "supported".

If the UDM has not requested an acknowledgement from the UE then step 5 is skipped; and

b) if the selected PLMN is a VPLMN or a non-subscribed SNPN, the security check is not successful and the UE is in automatic network selection mode, then:

- if the UE has a stored SOR-CMCI, the current PLMN is considered as lowest priority and the UE shall apply the actions in clause　C.4.2;

- otherwise, the UE shall wait until it moves to idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see 3GPP　TS　24.501) before attempting to obtain service on a higher priority PLMN as specified in clause　4.4.3.3 by acting as if timer T that controls periodic attempts has expired, with an exception that the current PLMN is considered as lowest priority, or before attempting to obtain service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current registered SNPN is considered as lowest priority. If the selected PLMN or SNPN is a VPLMN or a non-subscribed SNPN and the UE has an established emergency PDU session then the UE shall attempt to perform the PLMN selection after the emergency PDU session is released and after the UE enters idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see 3GPP　TS　24.501).

Step 5 is skipped;

NOTE　5: When the UE is in the manual mode of operation or the current chosen VPLMN is part of the "User Controlled PLMN Selector with Access Technology" list or the current chosen non-subscribed SNPN is part of the user controlled prioritized list of preferred SNPNs for the selected entry of the "list of subscriber data" the selected PLMN subscription, the UE stays on the VPLMN or non-subscribed SNPN.

5) The AMF to the UDM: If the UL NAS TRANSPORT message with an SOR transparent container is received, the AMF uses the Nudm_SDM_Info service operation to provide the received SOR transparent container to the UDM. If the HPLMN decided that the UE is to acknowledge successful security check of the received steering of roaming information in step 2, the UDM verifies that the acknowledgement is provided by the UE. The UDM shall store the "ME support of SOR-CMCI" indicator and the "ME support of SOR-SNPN-SI" indicator, if any; and

6) The UDM to the SOR-AF: Nsoraf_SoR_Info (SUPI of the UE, successful delivery, "ME support of SOR-CMCI" indicator, "ME support of SOR-SNPN-SI" indicator, if any). If the HPLMN policy for the SOR-AF invocation is present and the HPLMN UDM received and verified the UE acknowledgement in step 5, then the UDM informs the SOR-AF about successful delivery of the SOR-CMCI to the UE. The UDM shall include the "ME support of SOR-CMCI" indicator and the "ME support of SOR-SNPN-SI" indicator, if any.

If the selected PLMN is a VPLMN or a non-subscribed SNPN and:

- the UE in manual mode of operation encounters security check failure of SOR information in DL NAS TRANSPORT message; and

- upon switching to automatic network selection mode the UE remembers that it is still registered on the PLMN the non-subscribed SNPN where the security check failure of SOR information was encountered;

the UE shall wait until it moves to idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see　3GPP　TS　24.501　) before attempting to obtain service on a higher priority PLMN as specified in clause　4.4.3.3, by acting as if timer T that controls periodic attempts has expired, with an exception that the current registered PLMN is considered as lowest priority, or before attempting to obtained service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current registered SNPN is considered as lowest priority. If the selected PLMN is a VPLMN or the selected SNPN is a non-subscribed SNPN and the UE has an established emergency PDU session then the UE shall attempt to perform the PLMN selection after the emergency PDU session is released and after the UE enters idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see 3GPP　TS　24.501　).

NOTE　6: The receipt of the steering of roaming information by itself does not trigger the release of the emergency PDU session.C.5 Flow example for steering of UE in SNPN during registration

The flow example for the case when the UE registers in a non-subscribed SNPN is described below in figure C.5.1. The AMF is located in the non-subscribed SNPN. The UDM is located in the HPLMN or subscribed SNPN.

For the steps below, security protection is described in 3GPP TS 33.501.

1) The UE to the AMF: The UE initiates initial registration, emergency registration or registration procedure for mobility and periodic registration update (see 3GPP TS 24.501 ) to the AMF by sending REGISTRATION REQUEST message with the 5GS registration type IE indicating "initial registration", "emergency registration" or "mobility registration updating";

2) Upon receiving the REGISTRATION REQUEST message, the AMF executes the registration procedure as defined in FIGS. 5 and 6. As part of the registration procedure:

a) the AMF provides the registration type to the UDM using Nudm_UECM_Registration. As a consequence, in case of the 5GS registration type message indicates "initial registration" or "emergency registration" the UDM shall delete the stored "ME support of SOR-CMCI" indicator, if any, in UDR using Nudr_DM_Update service operation (see 3GPP　TS　23.502).

In addition:

a) if the AMF does not have subscription data for the UE, the AMF invokes Nudm_SDM_Get service operation to the UDM to get amongst other information the Access and Mobility Subscription data for the UE (see step　14b in FIGS. 5 and 6); or

b) if the AMF already has subscription data for the UE and:

i) the 5GS registration type IE in the received REGISTRATION REQUEST message indicates "initial registration" and the "SoR Update Indicator for Initial Registration" field in the UE context is set to 'the UDM requests the AMF to retrieve SoR information when the UE performs NAS registration type "initial registration"' as specified in table　5.2.2.2.2-1 of 3GPP　TS　23.502); or

ii) the 5GS registration type IE in the received REGISTRATION REQUEST message indicates "emergency registration" and the "SoR Update Indicator for Emergency Registration" field in the UE context is set to 'the UDM requests the AMF to retrieve SoR information when the UE performs NAS registration type "emergency registration"' as specified in table　5.2.2.2.2-1 of 3GPP　TS　23.502);

then the VPLMN AMF invokes Nudm_SDM_Get service operation message to the HPLMN UDM to retrieve the steering of roaming information (see step　14b in FIGS. 5 and 6);

otherwise the AMF sends a REGISTRATION ACCEPT message without the steering of roaming information to the UE and

steps

3a, 3b, 3c, 3d, 4, 5, 6 are skipped;

3a) If the user subscription information indicates to send the steering of roaming information due to initial registration in a non-subscribed SNPN, then the UDM shall provide the steering of roaming information to the UE when the UE performs initial registration in a non-subscribed SNPN. Otherwise:

a) If the UE is registering on the subscribed SNPN and the UE has not indicated support for SOR-SNPN-SI in the REGISTRATION REQUEST message, the UDM shall not provide the SOR-SNPN-SI to the UE; and

b) If the UE is registering on the subscribed SNPN and the UE has indicated support for SOR-SNPN-SI in the REGISTRATION REQUEST message, or the UE is not registering on the subscribed SNPN, the UDM may provide the SOR-SNPN-SI to the UE based on the subscribed SNPN or HPLMN policy.

If the UDM is to provide the steering of roaming information to the UE when the UE performs the registration in a non-subscribed SNPN and the subscribed SNPN or HPLMN policy for the SOR-AF invocation is absent then steps 3b and 3c are not performed and the UDM obtains the available SOR-SNPN-SI (i.e. all retrieved from the UDR). In addition, if the UDM obtains the SOR-SNPN-SI and the "ME support of SOR-CMCI" indicator is stored for the UE, then the UDM shall obtain the SOR-CMCI, if available, otherwise the UDM shall not obtain the SOR-CMCI. If the SOR-CMCI is provided then the UDM may indicate to the UE to store the SOR-CMCI in the ME by providing the "Store the SOR-CMCI in the ME" indicator.

If the UDM is to provide the steering of roaming information to the UE when the UE performs the registration in a non-subscribed SNPN and the subscribed SNPN or HPLMN policy for the SOR-AF invocation is present, then the UDM obtains the SOR-SNPN-SI, SOR-CMCI, if any, from the SOR-

AF using steps

3b and 3c;

3b) The UDM to the SOR-AF: Nsoraf_SoR_Get request (SNPN identity, SUPI of the UE, access type (see 3GPP　TS　29.571 V18.0.0)). The SNPN identity and the access type parameters, indicating where the UE is registering, are stored in the UDM;

3c) The SOR-AF to the UDM: Nsoraf_SoR_Get response (the SOR-SNPN-SI, the SOR-CMCI, if any, and the "Store the SOR-CMCI in the ME" indicator, if any);

Based on the information received in step 3b and any subscribed SNPN or HPLMN specific criteria, the SOR-AF may include the SOR-SNPN-SI, the SOR-CMCI, if any, and optionally the "Store the SOR-CMCI in the ME" indicator, if any.

If the SOR-AF includes the SOR-SNPN-SI and the ME supports the SOR-CMCI, the SOR-AF may provide the SOR-CMCI and optionally the "Store the SOR-CMCI in the ME" indicator, otherwise the SOR-AF shall provide neither the SOR-CMCI nor the "Store the SOR-CMCI in the ME" indicator.

3d) The UDM forms the steering of roaming information as specified in 3GPP　TS　33.501　from the SOR-SNPN-SI, the SOR-CMCI, if any, and the "Store the SOR-CMCI in the ME" indicator, if any, obtained in step 3a or the SOR-SNPN-SI, the SOR-CMCI, if any, and the "Store the SOR-CMCI in the ME" indicator, if any, obtained in step 3c.

If:

- the SOR-SNPN-SI was not obtained in

steps

3a or 3c; or

- the SOR-AF has not sent to the UDM an Nsoraf_SoR_Get response (step 3c) within an operator defined time after the UDM sending to the SOR-AF an Nsoraf_SoR_Get request (step 3b);

and the UE is performing initial registration in a non-subscribed SNPN and the user subscription information indicates to send the steering of roaming information due to initial registration in a non-subscribed SNPN, then the UDM forms the steering of roaming information as specified in 3GPP　TS　33.501　 from the subscribed SNPN or HPLMN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided';

4) The UDM to the AMF: The UDM sends a response to the Nudm_SDM_Get service operation to the AMF, which includes the steering of roaming information within the Access and Mobility Subscription data. The Access and Mobility Subscription data type is defined in clause　5.2.3.3.1 of 3GPP　TS　23.502　).

If the UE is performing initial registration or emergency registration and the UDM supports SOR-CMCI, the HPLMN shall request the UE to acknowledge the successful security check of the received steering of roaming information, by providing the indication as part of the steering of roaming information in the Nudm_SDM_Get response service operation. Otherwise, the subscribed SNPN or HPLMN may request the UE to acknowledge the successful security check of the received steering of roaming information, by providing the indication as part of the steering of roaming information in the Nudm_SDM_Get response service operation;

5) The AMF to the UDM: As part of the registration procedure, the SNPN also invokes Nudm_SDM_Subscribe service operation to the UDM to subscribe to notification of changes of the subscription data (e.g. received in step 4) including notification of updates of the steering of roaming information included in the Access and Mobility Subscription data (see step　14c in FIGS. 5 and 6　);

6) The AMF to the UE: The AMF shall transparently send the received steering of roaming information to the UE in the REGISTRATION ACCEPT message;

7) If the steering of roaming information is received and the security check is successful, then:

a) if the UDM has not requested an acknowledgement from the UE, then the UE shall send the REGISTRATION COMPLETE message to the serving AMF without including an SOR transparent container; and

b) if the steering of roaming information contains the SOR-SNPN-SI, the ME shall replace the credentials holder controlled prioritized lists of preferred SNPNs for the selected entry of the "list of subscriber data" or the selected PLMN subscription with the received credentials holder controlled prioritized lists of preferred SNPNs, if any, and the ME shall replace the credentials holder controlled prioritized lists of GINs for the selected entry of the "list of subscriber data" or the selected PLMN subscription with the received credentials holder controlled prioritized lists of GINs, if any, and delete the SNPNs identified by the credentials holder controlled prioritized lists of preferred SNPNs or credentials holder controlled prioritized lists of GINs from the list of "temporarily forbidden SNPNs" and the list of "permanently forbidden SNPNs", if they are present in these lists. Additionally, the UE may perform SNPN selection. If the UE decides to perform SNPN selection:

i) if the UE has a list of available and allowable SNPN in the area and based on this list or any other implementation specific means the UE determines that there is a higher priority SNPN than the selected SNPN; or

ii) the UE does not have a list of available and allowable SNPN in the area and is unable to determine whether there is a higher priority SNPN than the selected SNPN using any other implementation specific means;

and the UE is in automatic network selection mode:

A) if the UE is configured with the SOR-CMCI or received the SOR-CMCI over N1 NAS signalling, the UE shall apply the actions in clause　C.4.2. In this case steps 8 to 11 are skipped;

B) otherwise, the UE shall:

i) release the current N1 NAS signalling connection locally and then attempt to obtain service on a higher priority SNPN as specified in clause　4.9.3. In this case, steps 8 to 11 are skipped. The UE shall suspend the transmission of 5GSM messages until the N1 NAS signalling is released. If the UE has an established emergency PDU session (see　3GPP　TS　24.501　), the receipt of the steering of roaming information shall not trigger the release of the N1 NAS signalling connection. The UE shall release the current N1 NAS signalling connection locally subsequently after the emergency PDU session is released. If the UE needs to disable the N1 mode capability (see 3GPP　TS　24.501　) and there is no emergency service pending, the UE shall first attempt to obtain service on a higher priority SNPN as described in this step, and if no higher priority SNPN can be selected but the last registered SNPN is selected, then the UE shall disable the N1 mode capability; or

ii) not release the current N1 NAS signalling connection locally (e.g. if the UE has established PDU session(s)) and skip steps 8 to 10;

C.6 Flow example for steering of UE in SNPN after registration

The flow example for the steering of UE in SNPN after registration is indicated in FIG. 7. The UE is registered on an SNPN which can be the subscribed SNPN or a non-subscribed SNPN. The AMF is located in the selected SNPN. The UDM is located in the HPLMN or subscribed SNPN.

The procedure is triggered:

- If the UDM supports obtaining SOR-SNPN-SI and SOR-CMCI, if any, from the SOR-AF, the subscribed SNPN or HPLMN policy for the SOR-AF invocation is present in the UDM and the SOR-AF provides the UDM with SOR-SNPN-SI for a UE identified by SUPI. If the ME supports the SOR-CMCI, the SOR-AF may provide the SOR-CMCI and optionally provides the "Store the SOR-CMCI in the ME" indicator otherwise the SOR-AF shall provide neither the SOR-CMCI nor the "Store the SOR-CMCI in the ME" indicator; or

- When a SOR-SNPN-SI becomes available in the UDM (i.e. retrieved from the UDR). If the "ME support of SOR-CMCI" indicator is stored for the UE, the HPLMN UDM shall obtain the SOR-CMCI and the "Store the SOR-CMCI in the ME" indicator, if available, otherwise the HPLMN UDM shall obtain neither the SOR-CMCI nor the "Store the SOR-CMCI in the ME" indicator.

Refer to FIG. 7, FIG. 7 also shows Procedure for providing SOR-SNPN-SI after registration.

For the steps below, security protection is described in 3GPP　TS　33.501.

1) The SOR-AF to the UDM: Nudm_ParameterProvision_Update request is sent to the UDM to trigger the update of the UE with the SOR-SNPN-SI, the SOR-CMCI, if any, and the "Store the SOR-CMCI in the ME" indicator, if any, for a UE identified by SUPI.

2) The UDM to the AMF: The UDM notifies the changes of the user profile to the affected AMF by the means of invoking Nudm_SDM_Notification service operation. The Nudm_SDM_Notification service operation contains the steering of roaming information that needs to be delivered transparently to the UE over NAS within the Access and Mobility Subscription data. If the subcribed SNPN or HPLMN decided that the UE is to acknowledge successful security check of the received steering of roaming information, the Nudm_SDM_Notification service operation also contains an indication that the UDM requests an acknowledgement from the UE as part of the steering of roaming information. If the SOR-CMCI was obtained, the UDM shall include the SOR-CMCI into the steering of roaming information and shall requests an acknowledgement from the UE as part of the steering of roaming information. If the "Store the SOR-CMCI in the ME" indicator was obtained, the HPLMN UDM shall include the "Store the SOR-CMCI in the ME" indicator;

4) Upon receiving the steering of roaming information, the UE shall perform a security check on the steering of roaming information included in the DL NAS TRANSPORT message to verify that the steering of roaming information is provided by the subcribed SNPN or HPLMN, and

i if the security check is successful, then:

a) if the steering of roaming information contains the SOR-SNPN-SI, the ME shall replace the credentials holder controlled prioritized lists of preferred SNPNs for the selected entry of the "list of subscriber data" or the selected PLMN subscription with the received credentials holder controlled prioritized lists of preferred SNPNs, if any, the ME shall replace the credentials holder controlled prioritized lists of GINs for the selected entry of the "list of subscriber data" or the selected PLMN subscription with the received credentials holder controlled prioritized lists of GINs, if any, and the ME shall delete the SNPNs identified by the credentials holder controlled prioritized lists of preferred SNPNs or credentials holder controlled prioritized lists of GINs from the list of "temporarily forbidden SNPNs" and the list of "permanently forbidden SNPNs", if they are present in these lists.

b) If the UDM has requested an acknowledgement from the UE in the DL NAS TRANSPORT message, the UE sends an UL NAS TRANSPORT message to the serving AMF with an SOR transparent container including the UE acknowledgement and the UE shall set the "ME support of SOR-CMCI" indicator to "supported".

c) If the UE is in automatic network selection mode, the selected SNPN is a non-subscribed SNPN and the UE decides to perform SNPN selection, then:

- if the UE is configured with the SOR-CMCI or received the SOR-CMCI over N1 NAS signalling, the UE shall apply the actions in clause　C.4; or

- the UE shall wait until it moves to idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see 3GPP　TS　24.501) before attempting to obtain service on a higher priority SNPN as specified in clause　4.9.3.

d) If the selected SNPN is a non-subscribed SNPN and the UE has an established emergency PDU session then the UE may attempt to perform the SNPN selection subsequently after the emergency PDU session is released, if the UE is in automatic network selection mode.

e) If the UDM has not requested an acknowledgement from the UE, then steps 4 is skipped; and

ii)the security check is not successful:

a) step 5 is skipped; and

b) if the selected SNPN is a non-subscribed SNPN and the UE is in automatic network selection mode, then:

A) if the UE has a stored SOR-CMCI, then:

- if there are ongoing PDU sessions or services, the UE shall apply the actions in clause　C.4.2, and the current SNPN is considered as lowest priority; or

- if there are no ongoing PDU sessions or services, the UE shall release the current N1 NAS signalling connection locally and attempt to obtain service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current SNPN is considered as lowest priority;

B) if the UE does not have a stored SOR-CMCI, then:

- if there are ongoing PDU sessions or services, the UE shall wait until it moves to idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see 3GPP　TS　24.501　) before attempting to obtain service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current SNPN is considered as lowest priority. If the selected SNPN is a non-subscribed SNPN and the UE has an established emergency PDU session, then the UE shall attempt to perform the SNPN selection after the emergency PDU session is released; or

- if there are no ongoing PDU sessions or services, the UE shall release the current N1 NAS signalling connection locally and attempt to obtain service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current SNPN is considered as lowest priority.

5) The AMF to the UDM: If the UL NAS TRANSPORT message with an SOR transparent container is received, the AMF uses the Nudm_SDM_Info service operation to provide the received SOR transparent container to the UDM. If the subcribed SNPN or HPLMN decided that the UE is to acknowledge successful security check of the received steering of roaming information in step 1, the UDM verifies that the acknowledgement is provided by the UE. If the "ME support of SOR-CMCI" indicator in the header of the SOR transparent container is set to "supported", then the HPLMN UDM shall store the "ME support of SOR-CMCI" indicator, otherwise the HPLMN UDM shall delete the stored "ME support of SOR-CMCI" indicator, if any.

If the present flow was invoked by the UDM after receiving from the SOR-AF the SOR-SNPN-SI, SOR-CMCI, if any, for a UE identified by SUPI using an Nudm_ParameterProvision_Update request, and the UDM verification of the UE acknowledgement is successful, then the UDM informs the SOR-AF about successful delivery of the SOR-SNPN-SI, SOR-CMCI, if any, using Nsoraf_SoR_Info (SUPI of the UE, successful delivery); and

6) The UDM to the SOR-AF: Nsoraf_SoR_Info (SUPI of the UE, successful delivery, "ME support of SOR-CMCI" indicator, if any). If the subscribed SNPN or HPLMN policy for the SOR-AF invocation is present and the UDM received and verified the UE acknowledgement in step 5, then the UDM informs the SOR-AF about successful delivery of the SOR-SNPN-SI, SOR-CMCI, if any, to the UE. If the "ME support of SOR-CMCI" indicator is stored for the UE, the HPLMN UDM shall include the "ME support of SOR-CMCI" indicator;

If the selected SNPN is a non-subscribed SNPN and:

- upon switching to automatic network selection mode, the UE remembers that it is still registered on the where the security check failure of SOR information was encountered;

the UE shall wait until it moves to idle mode or 5GMM-CONNECTED mode with RRC inactive indication (see　3GPP　TS　24.501) before attempting to obtain service on a higher priority SNPN as specified in clause　4.9.3, with an exception that the current registered SNPN is considered as lowest priority. If the selected SNPN is a non-subscribed SNPN and the UE has an established emergency PDU session, then the UE shall attempt to perform the SNPN selection after the emergency PDU session is released.

5GMM capability

The purpose of the 5GMM capability information element is to provide the network with information concerning aspects of the UE related to the 5GCN or interworking with the EPS. The contents might affect the manner in which the network handles the operation of the UE.

The 5GMM capability information element is coded as shown in Table 3 and tables 4 to 5.

The 5GMM capability is a type 4 information element with a minimum length of 3 octets and a maximum length of 15 octets.

8	7	6	5	4	3	2	1
5GMM capability IEI								octet	1
Length of 5GMM capability contents								octet 2
SGC	5G-IPHC-CP CIoT	N3 data		5G-CP CIoT	RestrictEC	LPP	HO attach	S1 mode	octet 3
RACS	NSSAA		5G-LCS	V2XCNPC5	V2XCEPC5	V2X		5G-UP CIoT	5GSRVCC	octet 4*
5G ProSe-l2relay	5G ProSe-dc	5G ProSe-dd	ER-NSSAI	5G-EHC-CP CIoT	multipleUP	WUSA	CAG	octet 5*
PR	RPR	PIV	NCR	NR-PSSI	5G ProSe-l3rmt	5G ProSe-l2rmt	5G ProSe-l3relay	octet	6*
UN-PER	ESI	NSAG	Ex-CAG	SSNPNSI	EventNotification	MINT	NSSRG	octet	7*
spare	spare	spare	spare	spare	spare	UAS	SBNS	octet	8*
0	0	0	0	0	0	0	0	octet 9-15
Spare								octet 9-15

Table 3 shows examples of 5GMM capability information element

EPC NAS supported (S1 mode) (octet 3, bit 1) Bit
1
0	S1 mode not supported
1	S1 mode supported

ATTACH REQUEST message containing PDN CONNECTIVITY REQUEST message for handover support (HO attach) (octet 3, bit 2) Bit
2
0		ATTACH REQUEST message containing PDN CONNECTIVITY REQUEST message with request type set to "handover" or "handover of emergency bearer services" to transfer PDU session from N1 mode to S1 mode not supported
1		ATTACH REQUEST message containing PDN CONNECTIVITY REQUEST message with request type set to "handover" or "handover of emergency bearer services" to transfer PDU session from N1 mode to S1 mode supported

LTE Positioning Protocol (LPP) capability (octet 3, bit 3) Bit
3
0	LPP in N1 mode not supported
1	LPP in N1 mode supported (see 3GPP　TS　37.355　)

Restriction on use of enhanced coverage support (RestrictEC) (octet 3, bit 4) This bit indicates the capability to support restriction on use of enhanced coverage. Bit
4
0	Restriction on use of enhanced coverage not supported
1	Restriction on use of enhanced coverage supported
Control plane CIoT 5GS optimization (5G-CP CIoT) (octet 3, bit 5) This bit indicates the capability for control plane CIoT 5GS optimization. Bit
5
0	Control plane CIoT 5GS optimization not supported
1	Control plane CIoT 5GS optimization supported
N3 data transfer (N3 data) (octet 3, bit 6) This bit indicates the capability for N3 data transfer. Bit
6
0	N3 data transfer supported
1	N3 data transfer not supported
IP header compression for control plane CIoT 5GS optimization (5G-IPHC-CP CIoT) (octet 3, bit 7) This bit indicates the capability for IP header compression for control plane CIoT 5GS optimization. Bit
7
0	IP header compression for control plane CIoT 5GS optimization not supported
1	IP header compression for control plane CIoT 5GS optimization supported

Service gap control (SGC) (octet 3, bit 8) Bit
8
0	service gap control not supported
1	service gap control supported

5G-SRVCC from NG-RAN to UTRAN (5GSRVCC) capability (octet 4, bit 1) Bit
1
0	5G-SRVCC from NG-RAN to UTRAN not supported
1	5G-SRVCC from NG-RAN to UTRAN supported (see 3GPP　TS　23.216　)
User plane CIoT 5GS optimization (5G-UP CIoT) (octet 4, bit 2) This bit indicates the capability for user plane CIoT 5GS optimization. Bit
2
0	User plane CIoT 5GS optimization not supported
1	User plane CIoT 5GS optimization supported

V2X capability (V2X) (octet 4, bit 3)
This bit indicates the capability for V2X, as specified in 3GPP　TS　24.587　.Bit
3
0		V2X not supported
1		V2X supported

V2X communication over E-UTRA-PC5 capability (V2XCEPC5) (octet 4, bit 4)
This bit indicates the capability for V2X communication over E-UTRA-PC5, as specified in 3GPP　TS　24.587　.
Bit
4
0		V2X communication over E-UTRA-PC5 not supported
1		V2X communication over E-UTRA-PC5 supported


Location Services (5G-LCS) notification mechanisms capability (octet 4, bit 6)Bit
6
0			LCS notification mechanisms not supported
1			LCS notification mechanisms supported (see 3GPP　TS　23.273　)
Network slice-specific authentication and authorization (NSSAA) (octet 4, bit 7) This bit indicates the capability to support network slice-specific authentication and authorization. Bit
7
0			Network slice-specific authentication and authorization not supported
1			Network slice-specific authentication and authorization supported

Radio capability signalling optimisation (RACS) capability (octet 4, bit 8) Bit
8
0			RACS not supported
1			RACS supported

Closed Access Group (CAG) capability (octet 5, bit 1) Bit
1
0			CAG not supported
1			CAG supported
WUS assistance (WUSA) information reception capability (octet 5, bit 2) Bit
2
0			WUS assistance information reception not supported
1			WUS assistance information reception supported

Multiple user-plane resources support (multipleUP) (octet 5, bit 3)
This bit indicates the capability to support multiple user-plane resources in NB-N1 mode.Bit
3 0 Multiple user-plane resources not supported 1 Multiple user-plane resources supported
Ethernet header compression for control plane CIoT 5GS optimization (5G-EHC-CP CIoT) (octet 5, bit 4) Bit
4
0			Ethernet header compression for control plane CIoT 5GS optimization not supported
1			Ethernet header compression for control plane CIoT 5GS optimization supported

Extended rejected NSSAI support (ER-NSSAI) (octet 5, bit 5)
This bit indicates the capability to support extended rejected NSSAI.Bit
5 0 Extended rejected NSSAI not supported 1 Extended rejected NSSAI supported
5G ProSe direct discovery (5G ProSe-dd) (octet 5, bit 6) This bit indicates the capability for 5G ProSe direct discovery. Bit
6
0		5G ProSe direct discovery not supported
1		5G ProSe direct discovery supported
5G ProSe direct communication (5G ProSe-dc) (octet 5, bit 7) This bit indicates the capability for 5G ProSe direct communication. Bit 7 0 5G ProSe direct communication not supported 1 5G ProSe direct communication supported 5G ProSe layer-2 UE-to-network-relay (5G ProSe-l2relay) (octet 5, bit 8) This bit indicates the capability to act as a 5G ProSe layer-2 UE-to-network relay UE Bit
8
0		Acting as a 5G ProSe layer-2 UE-to-network relay UE not supported
1		Acting as a 5G ProSe layer-2 UE-to-network relay UE supported
5G ProSe layer-3 UE-to-network-relay (5G ProSe-l3relay) (octet 6, bit 1) This bit indicates the capability to act as a 5G ProSe layer-3 UE-to-network relay UE Bit
1
0			Acting as a 5G ProSe layer-3 UE-to-network relay UE not supported
1			Acting as a 5G ProSe layer-3 UE-to-network relay UE supported
5G ProSe layer-2 UE-to-network-remote (5G ProSe-l2rmt) (octet 6, bit 2) This bit indicates the capability to act as a 5G ProSe layer-2 UE-to-network remote UE Bit
2
0			Acting as a 5G ProSe layer-2 UE-to-network remote UE not supported
1			Acting as a 5G ProSe layer-2 UE-to-network remote UE supported
5G ProSe layer-3 UE-to-network-remote (5G ProSe-l3rmt) (octet 6, bit 3) This bit indicates the capability to act as a 5G ProSe layer-3 UE-to-network remote UE Bit
3
0			Acting as a 5G ProSe layer-3 UE-to-network remote UE not supported
1			Acting as a 5G ProSe layer-3 UE-to-network remote UE supported

NR paging subgroup support indication (NR-PSSI) (octet 6, bit 4)
This bit indicates the capability to support NR paging subgrouping
Bit

4
0			NR paging subgrouping not supported
1			NR paging subgrouping supported

N1 NAS signalling connection release (NCR) (octet 6, bit 5)
This bit indicates whether N1 NAS signalling connection release is supported.
Bit
5
0			N1 NAS signalling connection release not supported
1			N1 NAS signalling connection release supported

Paging indication for voice services (PIV) (octet 6, bit 6)
This bit indicates whether paging indication for voice services is supported.
Bit
6
0			paging indication for voice services not supported
1			paging indication for voice services supported

Reject paging request (RPR) (octet 6, bit 7)
This bit indicates whether reject paging request is supported.
Bit
7
0			reject paging request not supported
1			reject paging request supported

Paging restriction (PR) (octet 6, bit 8)
This bit indicates whether paging restriction is supported.
Bit
8
0			paging restriction not supported
1			paging restriction supported

NSSRG (octet 7, bit 1)
This bit indicates the capability to support the NSSRG.Bit
1
0			NSSRG not supported
1			NSSRG supported
Minimization of service interruption (MINT) (octet 7, bit 2)
This bit indicates the capability to support Minimization of service interruption (MINT)Bit
2
0			MINT not supported
1			MINT supported
Event notification (EventNotification) (octet 7, bit 3)
This bit indicates the capability to support event notification for upper layersBit
3
0			Event notification not supported
1			Event notification supported

SOR-SNPN-SI (SSNPNSI) (octet 7, bit 4)This bit indicates the capability to support SOR-SNPN-SIBit
4
0			SOR-SNPN-SI not supported
1			SOR-SNPN-SI supported

Extended CAG information list support (Ex-CAG) (octet 7, bit 5)
This bit indicates the capability to support extended CAG information list.Bit
5
0			Extended CAG information list not supported
1			Extended CAG information list supported

NSAG (octet 7, bit 6)
This bit indicates the capability to support NSAG.Bit
6
0			NSAG not supported
1			NSAG supported

Equivalent SNPNs indicator (ESI) (octet 7, bit 7)
This bit indicates the capability to support equivalent SNPNs.Bit
7
0			Equivalent SNPNs not supported
1			Equivalent SNPNs supported

V2X communication over NR-PC5 capability (V2XCNPC5) (octet 4, bit 5)
This bit indicates the capability for V2X communication over NR-PC5, as specified in 3GPP　TS　24.587
Bit
5
0				V2X communication over NR-PC5 not supported
1				V2X communication over NR-PC5 supported

UN-PER (octet 7, bit 8)
This bit indicates the capability to support Unavailability period.Bit
8
0				unavailability period not supported
1				unavailability period supported

Slice-based N3IWF selection support (SBNS) (octet 8, bit 1)
This bit indicates the capability to support slice-based N3IWF selection.Bit
1
0				Slice-based N3IWF selection not supported
1				Slice-based N3IWF selection supported


UAS (octet 8, bit 2)
This bit indicates the capability to support UAS services.Bit
2
0				UAS services not supported
1				UAS services supported
Bits 3-8 in octet 8 and bits in octets 9 to 15 are spare and shall be coded as zero, if the respective octet is included in the information element.

Tables 4 to Table 6 show examples of 5GMM capability information element

SOR transparent container is explained.

An AMF trasmists registration accept message to a UE, after the UE transmits registration request message to the AMF. The purpose of the SOR transparent container information element in the REGISTRATION ACCEPT message is to provide the list of preferred PLMN/access technology combinations (or HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided'), or a secured packet (see 3GPP TS 23.122 annex C) and optional indication of an acknowledgement request, SOR-CMCI, request the storage of the received SOR-CMCI in the ME, and SOR-SNPN-SI (or subscribed SNPN or HPLMN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'). The purpose of the SOR transparent container information element in the REGISTRATION COMPLETE message is to indicate the UE acknowledgement of successful reception of the SOR transparent container IE in the REGISTRATION ACCEPT message as well as to indicate the ME support of SOR-CMCI and the ME support of SOR-SNPN-SI.

The SOR transparent container information element is coded as shown in Table 7 to Table 26.

The SOR transparent container is a type 6 information element with a minimum length of 20 octets.

8	7	6	5	4	3	2	1
SOR transparent container IEI								octet	1
Length of SOR transparent container contents								octet 2octet	3
SOR header								octet	4
SOR-MAC-IAUSF								octet 5-20
CounterSOR								octet 21-22
Secured packet								octet	23* - n*

Table 7 shows examples of SOR transparent container information element for list type with value "0" and SOR data type with value "0".

8	7	6	5	4	3	2	1
SOR transparent container IEI								octet	1
Length of SOR transparent container contents								octet 2octet	3
SOR header								octet	4
SOR-MAC-IAUSF								octet 5-20
CounterSOR								octet 21-22
PLMN ID and access technology list								octet	23-m

Table 8 shows examples of SOR transparent container information element for list type with value "1", SOR data type with value "0", and additional parameters with value "0".

8	7	6	5	4	3	2	1
SOR transparent container IEI								octet	1
Length of SOR transparent container contents								octet	2 octet 3
SOR header								octet	4
SOR-MAC-IAUSF								octet	5 octet 20
CounterSOR								octet	21 octet 22
Length of PLMN ID and access technology list								octet	23*
PLMN ID and access technology list								octet	24* octet m*
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	SSSI	SSCMI	SI	octet o
SOR-CMCI								octet (o+1)* octet p*
SOR-SNPN-SI								octet (p+1)* octet u*

Table 9 shows examples of SOR transparent container information element for list type with value "1", SOR data type with value "0", additional parameters with value "1".

PLMN ID 1	octet 23- 25
access technology identifier 1	octet 26- 27
...
PLMN ID n	octet (18+5n)-(20+5n)
access technology identifier n	octet (21+5n)-(22+5n)

Table 10 shows examples of PLMN ID and access technology list (m=22+5*n).

8	7	6	5	4	3	2	1
SOR transparent container IEI								octet	1
Length of SOR transparent container contents								octet 2octet	3
SOR header								octet	4
SOR-MAC-IUE								octet 5 - 20

Table 11 shows examples of SOR transparent container information element for SOR data type with value "1".

8	7	6	5	4	3	2	1
0Spare	0 Spare	0 Spare	AP	ACK	List type	List indication	SOR data type	octet	4

Table 12 shows examples of SOR header for SOR data type with value "0".

8	7	6	5	4	3	2	1
0Spare	0 Spare	0 Spare	0 Spare	0 Spare	MSSNPNSI	MSSI	SOR data type	octet	4

Table 13 shows examples of SOR header for SOR data type with value "1".

SOR-MAC-IAUSF (see NOTE　1), SOR-MAC-IUE (see NOTE　2) and CounterSOR (see NOTE　1) are coded as specified in 3GPP　TS　33.501　.

SOR data type (octet 4, bit 1)
0	The SOR transparent container carries steering of roaming information.
1	The SOR transparent container carries acknowledgement of successful reception of the steering of roaming information.

List indication (octet 4, bit 2) (see NOTE　1 and NOTE　5)
0	HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided'
1	list of preferred PLMN/access technology combinations is provided

List type (octet 4, bit 3) (see NOTE　1)
0	The list type is a secured packet.
1	The list type is a "PLMN ID and access technology list".

Acknowledgement (ACK) value (octet 4, bit 4) (see NOTE　1)
0	acknowledgement not requested
1	acknowledgement requested

Additional parameters (AP) value (octet 4, bit 5)
Bit
5
0	Additional parameters not included
1	Additional parameters included (see NOTE　3)

If the SOR data type is set to value "0", the list type bit is set to value "1", and the additional parameters bit is set to value "1" then: - the octet o is present.- if the list indication bit is set to "0" then the PLMN ID and access technology list field and the length of PLMN ID and access technology list field are absent. - if the list indication bit is set to "1" then the PLMN ID and access technology list field and the length of PLMN ID and access technology list field are present.

The secure packet is coded as specified in 3GPP　TS　31.115　. (see NOTE　1)

The PLMN ID and access technology list consists of PLMN ID and access technology identifier and are coded as specified in 3GPP　TS　31.102　 subclause　4.2.5. The PLMN ID and access technology identifier are provided in decreasing order of priority, i.e. PLMN ID 1 indicates highest priority and PLMN ID n indicates lowest priority. The PLMN ID and access technology list contains at minimum zero and at maximum 16 (decimal) PLMN IDs and access technology identifiers. (see NOTE　1)
ME support of SOR-CMCI indicator (MSSI) value (octet 4, bit 2) (see NOTE　2, NOTE　4)
0	SOR-CMCI not supported by the ME
1	SOR-CMCI supported by the ME
ME support of SOR-SNPN-SI indicator (MSSNPNSI) value (octet 4, bit 3) (see NOTE　2, NOTE　6)
0	SOR-SNPN-SI not supported by the ME
1	SOR-SNPN-SI supported by the ME

SOR-CMCI indicator (SI) value (octet o, bit 1)Bit
1
0	SOR-CMCI absent
1	SOR-CMCI present

If the SOR-CMCI indicator bit is set to "SOR-CMCI present", the SOR-CMCI field is present. If the SI bit is set to "SOR-CMCI absent", the SOR-CMCI field is absent.

Store SOR-CMCI in ME indicator (SSCMI) value (octet o, bit 2)Bit
2
0	Do not store SOR-CMCI in ME
1	Store SOR-CMCI in ME

SOR-CMCI (octet o+1 to octet p)The SOR-CMCI field is coded according to figure　9.11.3.51.7 and table　9.11.3.51.2.

SOR-SNPN-SI indicator (SSSI) value (octet o, bit 3)Bit
3
0	subscribed SNPN or HPLMN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'
1	SOR-SNPN-SI present

If the SSSI bit is set to "SOR-SNPN-SI present", the SOR-SNPN-SI field is present. If the SSSI bit is set to "subscribed SNPN or HPLMN indication that 'no change of the SOR-SNPN-SI stored in the UE is needed and thus no SOR-SNPN-SI is provided'", the SOR-SNPN-SI is absent.


NOTE　1: This bit or field applies for SOR header with SOR data type with value "0".NOTE　2: This bit or field applies for SOR header with SOR data type with value "1". NOTE　3: Additional parameters can be set to value "1" only when the ME supports SOR-CMCI or SOR-SNPN-SI, and the list type bit is set to value "1". NOTE　4: The "SOR-CMCI supported by the ME" is not set by a UE compliant to an earlier release of the specification. NOTE　5: This bit or field applies for SOR header with list type with value "1". NOTE　6: The "SOR-SNPN-SI supported by the ME" may only be set by a UE which supports access to an SNPN using credentials from a credentials holder and which is not operating in SNPN access operation mode.

Table 14 shows examples of SOR transparent container information element.

8	7	6	5	4	3	2	1
Length of SOR-CMCI contents								octet (o+1) octet (o+2)
SOR-CMCI rule 1								octet (o+3)* octet q*
SOR-CMCI rule 2								octet (q+1)* octet r*
...								octet (r+1)* octet s*
SOR-CMCI rule n								octet (s+1)* octet p*

Table 15 shows examples of SOR-CMCI.

SOR-CMCI rule:
The SOR-CMCI rule is coded according to figure　9.11.3.51.8 and table　9.11.3.51.3.

If the length of SOR-CMCI contents field indicates a length bigger than indicated in figure　9.11.3.51.7, receiving entity shall ignore any superfluous octets located at the end of the SOR-CMCI.

Table 16 shows examples of SOR-CMCI.

8	7	6	5	4	3	2	1
Length of SOR-CMCI rule contents								octet q+1 octet q+2
Tsor-cm timer value								octet q+3
Criterion type								octet q+4
Criterion value								octet (q+5)* octet r*

Table 17 shows examples of S SOR-CMCI rule.

Tsor-cm timer value
The Tsor-cm timer value field is coded according to octet 2 of the GPRS timer information element as specified in 3GPP　TS　24.008　 subclause　10.5.7.3 and indicates the Tsor-cm timer value. When the unit field of the Tsor-cm timer value field indicates that the timer is deactivated, the receiving entity shall consider that Tsor-cm timer value is set to the infinity value.

Criterion type

Bits8

7 6 5 4 3 2 1
0 0 0 0 0 0 0 1 DNN
0 0 0 0 0 0 1 0 S-NSSAI SST
0 0 0 0 0 0 1 1 S-NSSAI SST and SD
0 0 0 0 0 1 0 0 IMS registration related signalling
0 0 0 0 0 1 0 1 MMTEL voice call
0 0 0 0 0 1 1 0 MMTEL video call
0 0 0 0 0 1 1 1 SMS over NAS or SMSoIP
0 0 0 0 1 0 0 0 SOR security check not successful
1 1 1 1 1 1 1 1 match all
All other values are spare.

The receiving entity shall ignore SOR-CMCI rule with criterion of criterion type set to a spare value.

For "DNN", the criterion value field shall be encoded as a DNN length-value pair field.
For "S-NSSAI SST", the criterion value field shall be encoded as one octet SST field.

For "S-NSSAI SST and SD", the criterion value field shall be encoded as a sequence of one octet SST field and three octets SD field. The SST field shall be transmitted first.

The DNN length-value pair field shall be encoded as a sequence of one octet DNN value length field and a DNN value field. The DNN value length field shall be transmitted first. The DNN value length field indicates the length in octets of the DNN value field. The DNN value field contains an APN as specified in 3GPP　TS　23.003　.

The SST field contains SST of HPLMN's S-NSSAI.

The SD field contains SD of HPLMN's S-NSSAI.

For "match all", "SOR security check not successful", "IMS registration related signalling", "MMTEL voice call", "MMTEL video call", and "SMS over NAS or SMSoIP", the criterion value field is zero octets long.

If the length of SOR-CMCI rule contents field indicates a length bigger than indicated in figure　9.11.3.51.8, receiving entity shll ignore any superfluous octets located at the end of the SOR-CMCI rule.
The UE applies SOR-CMCI rules as described in 3GPP　TS　23.122　 annex　C.

Table 18 shows examples of S SOR-CMCI rule.

8	7	6	5	4	3	2	1
Length of SOR-SNPN-SI contents								octet (p+1) octet (p+2)
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	CLGI	CLSI	octet (p+3)
CH controlled prioritized list of preferred SNPNs								octet (p+4)* octet t*
CH controlled prioritized list of GINs								octet (t+1)* octet u*

Table 19 shows examples of SOR-SNPN-S.

CH controlled prioritized list of preferred SNPNs indicator (CLSI) value (octet p+3, bit 1) Bit
1
0	CH controlled prioritized list of preferred SNPNs absent
1	CH controlled prioritized list of preferred SNPNs present

If the CLSI bit is set to "CH controlled prioritized list of preferred SNPNs present", the CH controlled prioritized list of preferred SNPNs field is present. If the CLSI bit is set to "CH controlled prioritized list of preferred SNPNs absent", the CH controlled prioritized list of preferred SNPNs field is absent.

CH controlled prioritized list of GINs indicator (CLGI) value (octet p+3, bit 2)Bit
2
0	CH controlled prioritized list of GINs absent
1	CH controlled prioritized list of GINs present

If the CLGI bit is set to "CH controlled prioritized list of GINs present", the CH controlled prioritized list of GINs field is present. If the CLGI bit is set to "CH controlled prioritized list of GINs absent", the CH controlled prioritized list of GINs field is absent.

If the length of SOR-SNPN-SI contents field indicates a length bigger than indicated in figure　9.11.3.51.9, receiving entity shall ignore any superfluous octets located at the end of the SOR-SNPN-SI.

Table 20 shows examples of SOR-SNPN-SI.

8	7	6	5	4	3	2	1
Length of CH controlled prioritized list of preferred SNPNs contents								octet p+4 octet p+5
SNPN identity 1								octet (p+6)* octet (p+14)*
SNPN identity 2								octet (p+15)* octet (p+23)*
...								octet (p+24)* octet (p+n9-2)
SNPN identity n								octet (p+n9-3) octet (p+n9+5) = octet t*

Table 21 shows examples of CH controlled prioritized list of preferred SNPNs.

8	7	6	5	4	3	2	1
MCC digit 2				MCC digit 1				octet p+15
MNC digit 3				MCC digit 3				octet p+16
MNC digit 2				MNC digit 1				octet p+17
0 Spare	0 Spare	0 Spare	0 Spare	NID assignment mode				octet p+18
NID value digit 2				NID value digit 1				octet p+19
NID value digit 4				NID value digit 3				octet p+20
NID value digit 6				NID value digit 5				octet p+21
NID value digit 8				NID value digit 7				octet p+22
NID value digit 10				NID value digit 9				octet p+23

Table 22 shows examples of SNPN identity.

Mobile country code (MCC):
The MCC field is coded as in ITU-T　Recommendation　E.212　, annex　A.

Mobile network code (MNC):The coding of MNC field is the responsibility of each administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. If a network operator decides to use only two digits in the MNC, MNC digit 3 shall be coded as "1111".

NID assignment mode

NID assignment mode is coded as specified in 3GPP　TS　23.003　.

NID value

NID value is coded as specified in 3GPP　TS　23.003　.

Table 23 shows examples of CH controlled prioritized list of preferred SNPNs.

8	7	6	5	4	3	2	1
Length of CH controlled prioritized list of GINs contents								octet t+1 octet t+2
GIN 1								octet (t+3)* octet (t+11)*
GIN 2								octet (t+12)* octet (t+20)*
...								octet (t+21)* octet (t+n9-5)
GIN n								octet (t+n9-6) octet (t+n9+2) = octet u*

Table 24 shows examples of CH controlled prioritized list of GINs.

8	7	6	5	4	3	2	1
MCC digit 2				MCC digit 1				octet t+12
MNC digit 3				MCC digit 3				octet t+13
MNC digit 2				MNC digit 1				octet t+14
0 Spare	0 Spare	0 Spare	0 Spare	NID assignment mode				octet t+15
NID value digit 2				NID value digit 1				octet t+16
NID value digit 4				NID value digit 3				octet t+17
NID value digit 6				NID value digit 5				octet t+18
NID value digit 8				NID value digit 7				octet t+19
NID value digit 10				NID value digit 9				octet t+20

Table 25 shows examples of GIN.

NID assignment mode

NID assignment mode is coded as specified in 3GPP　TS　23.003　.

NID value

NID value is coded as specified in 3GPP　TS　23.003　.

Table 26 shows examples of CH controlled prioritized list of GINs.

The following description is related to UE discover, select and access to a Hosting network for Localized services.

According to the present disclosure, UE configuration and subscription aspects are explained.

An SNPN-enabled UE is configured with the following information for each subscribed SNPN:

- PLMN ID and NID of the subscribed SNPN;

- Subscription identifier (SUPI) and credentials for the subscribed SNPN;

- Optionally, an N3IWF FQDN and an identifier of the country where the configured N3IWF is located;

- Optionally, if the UE supports access to an SNPN using credentials from a Credentials Holder:

- User controlled prioritized list of preferred SNPNs;

- Credentials Holder controlled prioritized list of preferred SNPNs, each entry of the list includes;

- an SNPN identifier; and

- optionally, time validity information, e.g., the start and the end time of allowing to access an SNPN, if the UE supports access to an SNPN providing access for Localized services

- Credentials Holder controlled prioritized list of GINs, each entry of the list includes;

- a GIN; and

- Protection scheme for concealing the SUPI as defined in TS 33.501;

For an SNPN-enabled UE with SNPN subscription, the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs may be updated by the Credentials Holder using the Steering of Roaming (SoR) procedure as defined in Annex C of TS 23.122. Updating Credentials Holder controlled prioritized lists of preferred SNPNs and GINs via the Steering of Roaming (SoR) procedure is not applicable for Credentials Holder with AAA Server.

A subscription of an SNPN is either:

- identified by a SUPI containing a network-specific identifier that takes the form of a Network Access Identifier (NAI) using the NAI RFC 7542 based user identification as defined in clause 28.7.2 of TS 23.003 V18.0.0. The realm part of the NAI may include the NID of the SNPN; or

- identified by a SUPI containing an IMSI.

In the case of access to an SNPN using credentials owned by a Credentials Holder, the SUPI shall also contain identification for the Credentials Holder (i.e. the realm in the case of Network Specific Identifier based SUPI or the MCC and MNC in the case of an IMSI based SUPI). In the case of access to an SNPN using credentials owned by a Credentials Holder using AAA-S, only Network Specific Identifier based SUPI is supported.

An SNPN-enabled UE that supports access to an SNPN using credentials from a Credentials Holder and that is equipped with a PLMN subscription may additionally be configured with the following information for SNPN selection and registration using the PLMN subscription in SNPN access mode:

- User controlled prioritized list of preferred SNPNs;

- an SNPN identifier; and

- Credentials Holder controlled prioritized list of preferred GINs, each entry of the list includes;

- a GIN; and

For an SNPN-enabled UE with PLMN subscription, the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs may be updated by the Credentials Holder using the Steering of Roaming (SoR) procedure as defined in Annex C of TS 23.122.

When the Credentials Holder updates a UE with the Credentials Holder controlled prioritized lists of preferred SNPNs and GINs the UE may perform SNPN selection again, e.g. to potentially select a higher prioritized SNPN or to potentially select an SNPN that provides access for Localized services.

According to the present disclsoure, Network selection in SNPN(e.g., clause 5.30.2.4 of TS 23.501)is explained.

An SNPN-enabled UE supports the SNPN access mode. When the UE is set to operate in SNPN access mode the UE selects and registers with SNPNs over Uu as described in clause 5.30.2.4. Network selection in SNPN access mode for access to SNPN services via Untrusted non-3GPP access, Trusted non-3GPP access and Wireline access is specified in clause 5.30.2.12, clause 5.30.2.13 and clause 5.30.2.14 of TS 23.502 respectively. Access network selection in SNPN access mode for 5G NSWO is specified in clause 6.3.12b.

Emergency services are supported in SNPN access mode over Uu as defined in clause 5.16.4.1. Support for Emergency in SNPN access mode via Untrusted non-3GPP access is specified in clause 5.30.2.12.

If a UE is not set to operate in SNPN access mode, even if it is SNPN-enabled, the UE does not select and register with SNPNs. A UE not set to operate in SNPN access mode performs PLMN selection procedures as defined in clause 4.4 of TS 23.122. For a UE capable of simultaneously connecting to an SNPN and a PLMN, the setting for operation in SNPN access mode is applied only to the Uu interface for connection to the SNPN. Clause D.4 provides more details.

An SNPN-enabled UE that supports access to an SNPN using credentials from a Credentials Holder and that is equipped with a PLMN subscription needs to first enter SNPN access mode to be able to select SNPNs. Once the UE has entered SNPN access mode, SNPN selection is performed as described in clause 5.30.2.4. Once an SNPN has been selected the UE attempts registration in the SNPN using the PLMN credentials.

When a UE is set to operate in SNPN access mode the UE does not perform normal PLMN selection procedures as defined in clause 4.4 of TS 23.122.

UEs operating in SNPN access mode read the information described in clause 5.30.2.2 from the broadcast system information and take them into account during network selection. Furthermore, if the UE supports access to an SNPN providing access for Localized services, and the end user enables to access the Localized services the UE may select an SNPN providing access for Localized services.

According to the present disclsoure, Automatic network selection (e.g., clause 5.30.2.4.2 of TS 23.501)is explained.

If the UE supports accessing an SNPN providing access for Localized services and the end user enables to access Localized services, for automatic network selection, the UE selects and attempts registration on available SNPN in the following order:

- if the UE supports access to an SNPN using Credentials from a Credentials Holder then the UE continues by selecting and attempting registration on available and allowable SNPNs which broadcasts the indication that access using credentials from a Credentials Holder is supported in the following order:

- SNPNs in the Credentials Holder controlled prioritized list of preferred SNPNs (in prioritized order) if time validity information is available and is met; The entries on the list of preferred SNPNs without time validity information are ignored;

- SNPNs, which additionally broadcast a GIN contained in the Credentials Holder controlled prioritized list of preferred GINs (in prioritized order) if time validity information is available and is met; The entries on the list of preferred GINs without time validity information are ignored.

- the SNPN not providing access for Localized services the UE was last registered with (if available) or the equivalent SNPN (if available);

- the subscribed SNPN, which is identified by the PLMN ID and NID for which the UE has SUPI and credentials;

- the available and allowable SNPNs which broadcast the indication that access using credentials from a Credentials Holder is supported in the following order:

- SNPNs in the user controlled prioritized list of preferred SNPNs (in priority order);

- SNPNs in the Credentials Holder controlled prioritized list of preferred SNPNs (in priority order) without time validity information;

- SNPNs, which additionally broadcast a GIN contained in the Credentials Holder controlled prioritized list of preferred GINs (in priority order) without time validity information;

- SNPNs, which additionally broadcast an indication that the SNPN allows registration attempts from UEs that are not explicitly configured to select the SNPN, i.e. the broadcasted NID or GIN is not present in the Credentials Holder controlled prioritized lists of preferred SNPNs/GINs in the UE.

If the UE supports accessing an SNPN providing access for Localized services and the end user enables to access Localized services the UE shall check regularly if SNPNs for which a validity condition is valid become available.

If the UE does not support to access an SNPN providing access for Localized services or the end user does not enable to access the Localized services, for automatic network selection the UE selects and attempts registration on available and allowable SNPNs in the following order:

- the subscribed SNPN, which is identified by the PLMN ID and NID for which the UE has SUPI and credentials.;

- If the UEs supports access to an SNPN using credentials from a Credentials Holder then the UE continues by selecting and attempting registration on available and allowable SNPNs which broadcast the indication that access using credentials from a Credentials Holder is supported in the following order:

- SNPNs in the Credentials Holder controlled prioritized list of preferred SNPNs (in priority order) without time validity information; The entries on the list of preferred SNPNs with time validity information are ignored;

- SNPNs, which additionally broadcast a GIN contained in the Credentials Holder controlled prioritized list of preferred GINs (in priority order) without time validity information; The entries on the list of preferred SNPNs with time validity information are ignored;

When a UE performs Registration or Service Request to an SNPN, the UE shall indicate the PLMN ID and NID as broadcast by the selected SNPN to NG-RAN. NG-RAN shall inform the AMF of the selected PLMN ID and NID.

According to the present disclosure, a UE may support Standalone Non-Public Network (SNPN). The SNPN-capable UE may receive the steering of roaming (SoR) information during the registration procedure. The UE may store the information in a non-volatile memory in the mobile terminal, which may be the UE. If time information is included in the SoR information, the UE starts a timer baed on the time information upon reception of the time information. The UE may perform actions when the timer stops or expires as illustrated in Figure 11.

According to FIG. 9, the UE may include Mobile Terminal (MT) and Subscriber Identity Module (SIM). Also, the UE may include Universal SIM Application Toolkit (USAT). The UE may allow the SIM card in the UE to interact with applications and services provided by a network operator.

The USAT provides mechanisms which allow applications(e.g., SIM application), existing in the Universal Integrated Circuit Card (UICC), to interact and operate with any Mobile Equipment (ME) which supports the specific mechanism(s) required by the application. NVM is non-volatile memory. NVM is a storage that storing data being not deleted even when the UE being switched off to switched on or vice versa.

The UE may perform the following operation:

i) The UE may receive SoR information including time information (e.g., via NAS signalling). For example, the UE may receive the SoR information from an AMF.

ii) The UE may store SoR information, if required, in a non-volatile memory (NVM) in the MS or in the (U)SIM. (e.g., via USAT REFRESH command).

iii) The UE may start a timer based on the SoR information received in Step i).

iv) The UE may perform actions when the timer started in Step iii) stops or expires, or stop the timer based on a particular event (e.g., Protocol Data Unit (PDU) session release).

For example, the HPLMN may provision the SoR over control-plane information (SOR-CMCI) in the UE to control the timing of a UE. Upon the reception of the SoR over control-plane information, the UE stores the received information in the non-volatile memory of the ME or in the USIM, and may start the timer depending on the condition (e.g., whether the associated ongoing PDU session exists). After that, when the timer stops in particular cases (e.g., state transition), the UE starts a PLMN selection procedure.

There may be a new use case that a network operator wants to support a service for a weekly event (e.g., weekly flee market) and provide the information to UEs. Then, the UEs receiving the weekly event service may need to select a network supporting the weekly event only when the event is held.

To support this kind of use case examples, legacy SoR mechanism has to be enhanced. In prior art, a legacy SoR mechanism does not support a case that the UE receives more than one time information, which have dependency with each other, in the SoR information. However, more than two time information, which have dependency with each other, may need to be informed to a UE to identify a weekly event. Thus, there are problems that recurrent events, such as weekly events, cannot be effectively supported by the UE and the network.

Therefore, there's a need that the enhanced SoR mechanism to handle more than two time information is considered.

In conventional SoR technology, the network communicates a single independent timer to the UE. At the expiration of that timer, the UE performs network selection. The connected mode UE transitions to idle mode and performs network selection when the Tsor-cm timer expires, which is communicated in the SoR-CMCI (Connected Mode Control Information).

SNPN services that support recurrent events may be supported, or network slicing may be enabled. According to the prior art, SoR based network selection is performed with only one independent timer information. In this case, the UE has to perform SoR signaling reception repeatedly for each recurrent event. Therefore, according to the prior art, efficient signaling reception and network selection operation is not possible.

In prior art, the available time information for a specific resource delivered from the network to the UE may only consist of start time/end time, considering use cases consisting of one shot events. Herein, one shot events may mean that an event happens one time. For example, use cases with recurrent events such as weekly flee market are not considered in the prior art. However, if the prior art signaling format is used for recurrent events, the following behavior can be performed. For example, 1) the network would need to send the start time/end time for each event to the UE each time the event occurs. In another example, 2) the network must send the UE the start time/end time for a large time range that includes all recurrent events. However, the problem with 1) is that the same information needs to be signaled repeatedly. This can result in wasted network resources. In addition, in case 2), unavailable time duration is also interpreted as available time duration. This can lead to inaccurate communication.

Based on examples of the present disclosure, the above mentioned problems can be solved.

To implement the mechanism for a UE to select a network providing a periodic localized service, the following operations may be performed. For example, the UE may receive more than one time information, which have dependency with each other, via SoR procedure. The UE may start a timer stored in the UE storage (e.g., NVM or (U)SIM) upon expiry of another timer.

According to implementations of the present disclosure, following examples are explained.

- SoR information including time information can be delivered to an MT via NAS signalling, AT command, or over-the-air interface. For example, a network (e.g., AMF) may transmit the SoR informaiton including the time information to the UE including the MT.

The time information for Localized service may include one or more of:

- Information to identify an event (localized service). The information to ientify an event may include absolute time of the start time of a periodic event (e.g., YYYY-MM-DD). The information to ientify an event may include absolute time of the end time of a periodic event. The information to ientify an event may include frequency of an events held (e.g., N number of events). The information to ientify an event may include periodicity (e.g., 7 days, Saturday, Midnight, NA (maybe meaning an infinite value), and so on). For example, based on the information to identify an event, a UE may know when the SNPN supporting a particular localized service has the highest priority; and/or

- Information to perform particular actions during the event. For example, this information may include duration (e.g., 8 hours, 9AM ~ 6PM). For example, based on the information to perform particular actions during the event, a UE may perform SNPN selection procedure where the SNPN supporting a particular localized service the highest priority.

Refer to FIG. 10, periodicity of an event (T1) and duration of an event (T2) are shown. The UE may receive SoR information including T1 and/or T2 from the AMF. As shown in FIG. 10, recurrent events may occur based on the periodicity of the event during the duration of the event.

For example, if the recurrent event is a flee market, T1 may be 7 days. T2 may be 8 hours from 9AM.

In the present disclosure, each time information may include more than one information fields. For example, duration of the event may be set using one filed <8 hours>, or two fields <unit of time> and <8>.

FIGS. 11a to 11c shows examples of an overall procedure.

FIG. 11a shows example of of UE. UE may include MT, SIM, and Terminal Equipment (TE). MT, NVM, SIM, USAT may be same as the example of FIG. 9. AT command means a text command language to control the TE.

In step S1101, the UE may receive SoR information from a network. The UE may receive the SoR information via NG-RAN from an AMF. The SoR information may include time information to identify an event and time information to identify the duration of the event.

In step S1102, if required, the UE may store the received SoR information. For example, the UE may store the received SoR information in the NVM in the MS or in the (U)SIM, if required.

The SoR information includes information related to recurrent events (e.g., localized services). For example, T_start which menas the start of the event may be included. For example, T1 which menas the periodicity of the event may be included. For example, T2 which menas the duration of the event may be included. For example, N which menas the frequency of the event may be included. For example, T_end which menas the end of the event may be included.

In step S1103, the UE may start T_start. For exmaple, when the event starts, the UE may start T_start.

In step S1104, T_start may expire. Upon expiry of T_start, the UE may start T1 and/or T2.

In step S1105, the UE may perform SNPN selection procedure for the localized service (e.g., recurrent events).

In step S1106, if a timer based on T2 expires, step S1107 may be performed.

In step S1107, the UE may perform legacy SNPN selection procedure.

In step S1108, if a timer based on T1 expires, step S1109 may be performed.

In step S1109, the UE may start T2, and/or re-start T1. The UE may perform SNPN selection for the localized service (e.g., recurrent events).

In step S1110, if a timer based on T2 expires, step S1111 may be performed.

In step S1111, the UE may perform legacy SNPN selection procedure.

In step S1112, if a timer based on T_end expires, or N becomes 0, step S1113 may be performed.

In step S1113, the UE may delete the SoR information.

Example operations according to implementations of the present disclosure are as follows as presented in Figures 14a and 14b.

The UE may inlcude ATC, MT, USIM. Operaitons performed by ATC, MT, USIM all may also be referred to operations performed by the UE.

Oerations performed between ATC and MT, operaitons performed between the USIM and MT may be optional operations.

Step 1: The UE may receive localized service information.

- The UE may receive localized service information via SoR information via NAS signalling.

- The MT in the UE may receive localized service information via AT command.

- The received information may include more than one time information.

- The received more than one time information may be associated.

- The received time information fields received may be associated with each other. For example, time information 2 is valid only if time information 1 is valid. For example, according to the present dislosure, time informaiton 1 may include T_start and/or T_end. Time informaiton may inlcude T1 and/or T2.

- The received information may include the associated action information.

For exmaple, The UE may receive SoR information from the SoR-AF. The SoR-AF may transmit the SoR information to the UE. The AMF may receive the SoR information from the SoR-AF. The AMF transmit SoR transparent container Information Element (IE) includint the SoR information to the UE. The SoR transparent container may be included in Registration accept message or DL NAS transport message. The SoR information may include PLMN information or SNPN information. The SoR information may include time information for localized services (e.g., recurrent events).

For exmaple, The MT may transmit AT command. AT information may include localized service+LSPS. LSPS may include network, time 1, time 2. AT command may include PLMN information or SNPN information. AT command may include time information for localized services (e.g., recurrent events).

Step 2: The UE may store time information and/or the associated action.

- The UE may store time and/or action information in a non-volatile memory in the MT.

- The UE may store time and/or action information in the (U)SIM.

- If the list of information cannot be stored (e.g., due to memory size limitation), the UE may store the number of N entries from the top of the list.

- The UE may store the maximum M number of entries of time and/or action information. The value of M can be configured via signalling from the network or AT command, or preconfigured in the UE.

Step 3: The UE may start a timer that identifies the initial start of localized service, T_start.

- The UE may start a timer upon reception of service information in Step 1.

- The UE may start a timer based on time information stored in a non-volatile memory in the MT.

- The UE may start a timer based on time information stored in the (U)SIM.

Step 4: T_start may be stopped or expired. Then, the UE performs step 6. The UE may perform step 5 before step 6.

Step 5: The UE may read SoR information in a non-volatile memory or in USIM.

Step 6: The UE may start a timer to identify the duration of the event.

- Upon expiry or stop of T_start, the UE may start more than one timer to identify one occurrence of the event using the localized service.

- The UE may start a timer to identify periodicity of the occurrence, T1.

- The UE may start a timer to identify duration of the event, T2.

- The UE may start a timer based on time information stored in the (U)SIM.

- The UE may perform actions corresponding to the localized service.

- The UE may perform prioritized SNPN selection for the event.

Step 7: T2 to identify the duration of the event may be stopped or expired. Then, the UE may perform legacy operation.

- The UE may perform legacy SNPN selection without considering prioritization of the SNPN providing the localized service.

Step 8: T1 may be stopped or expired. Then, the UE performs step 10. The UE may perform step 9 before step 10.

Step 9: The UE may read SoR information in NVM or in USIM.

Step 10: The UE may refresh (or restart) timer based on T1 and/or start timer based on T2.

Step 11: The UE may perform actions upon expiry of T2.

After Step 11, if the localized service ends (e.g., based on frequency or time information), the UE may delete SoR information for the localized service.

- Upon expiry of T_end , the UE may delete SoR information in a non-volatile memory in the MT.

- Upon expiry of T_end, the UE may delete SoR information in a non-volatile memory in the (U)SIM.

- If the frequency value, N, is equal to zero, the UE may delete SoR information in a non-volatile memory in the MT.

- If the frequency value, N, is equal to zero, the UE may delete SoR information in the (U)SIM.

FIG. 13 shows an example of a scenario according to the present disclosure.

FIG. 13 illustrates an example of an example of a scenario according to an embodiment of the present disclosure.

According to FIG. 13, start of the loclized service (e.g., recurrent event) may be 20th, February, 2023. T2 may be 8 hours. T1 may be 7 days. After some time, as marked in FIG. 13, the UE may delete localised service information after 12 occurrences.

Based on the example of FIG. 13, the following operations may be performed.

i) A UE may receive SoR information include one or more of the following:

A. Absolute time, "2023-02-20" of the start time of an event

B. Frequency, "12", of the event

C. Periodicity, "7 days", of the event

D. Duration, "8 hours", of the event

E. One or more SNPN information that provides a localized service of the event

ii) The UE may start a timer T_start to be expired on the start of the event, 2023-02-20.

iii) The UE may store one or more of the following:

A. the value of Frequency, 12, and

B. the value of a timer T1 for the periodicity, 10,080 minutes (equal to 7 days), and

C. the value of a timer T2 for the duration, 28,800 seconds (equal to 8 hours).

iv) Upon expiry of T_start, which is the first event start,

A, the UE may start a timer T1, to identify the next event start

B. the UE may start a timer T2, to identify the duration of the event

C. The UE may perform SNPN selection where the SNPN providing the localized service of the event has the highest priority.

D. The UE may decrease the frequency value by 1 if T2 starts.

v) Upon expiry of T2, the UE may perform legacy SNPN selection procedure.

vi) Upon expiry of T1,

A. the UE may start a timer T2, to identify the duration of the event

B. The UE may perform SNPN selection where the SNPN providing the localized service of the event has the highest priority.

C. The UE may decrease the frequency value by 1 if T2 starts.

i) The UE may repeat from Step vi) until the frequency value is equal to 0.

ii) The UE may delete the stored SoR information if the frequency value is equal to 0.

According to the invention, the UE receives more than one time information to provide periodic service provided by a particular network (e.g., SNPN). By receiving the periodic information via one message and storing it in the UE storage (e.g., NVM, SIM), signalling resource for periodic signalling update is unnecessary and UE can save power for processing periodic RX signalling. Also, handling periodic SoR procedure is unnecessary.

According to the present disclosure, Time information may be explained as the following.

In the present disclosure, "time information" may be used separately from T_start, T1, T2, and T3. This is because various examples are possible. For example, the time information parameter received by the UE in signaling may be the input to the timer value. In another example, the value calculated by the terminal based on the time information parameter may be the input to the timer value. Thus, time information may be used as a more general term than various timer values such as T_start, T1, T2, etc. For example, the UE may receive the T_start value directly from the network as the time information parameter. Alternatively, the UE may calculate T_start from the time it receives the time information parameter.

For example, Time information 1 may include time information that includes T_start/T_end. For example, the time information with T_start/T_end might mean March-June for a weekly flee market service. Time information 2 can include T1, T2 time information for recurrent events.

Referring to the example in Table 27, Time window start time/ Time window end time can correspond to T_start/T_end respectively. In Table 27, the parameters corresponding to Time information 2 can be Recurrence pattern, Recurrence contents, Recurrence start time/ Recurrence end time. For reference, information related to time in Tables 27 to 31 may be used by the UE and the network(e.g., the AMF).

8	7	6	5	4	3	2	1
0 Spare	0 Spare	RETI	RSTI	TWEDI	TWSDI	TWETI	TWSTI	octet a+3
Recurrence pattern								octet (a+4)
Recurrence contents								octet (a+5)*
								octet (a+6)*
Length of time window start time								octet (a+7)*
Time window start time								octet (a+8)* octet b*
Length of time window end time								octet (b+1)*
Time window end time								octet (b+2)* octet c*
Length of time window start date								octet (c+1)*
Time window start date								octet (c+2)* octet d*
Length of time window end date								octet (d+1)*
Time window end date								octet (d+2)* octet e*
Length of recurrence start time								octet (e+1)*
Recurrence start time								octet (e+2)* octet f*
Length of recurrence end time								octet (f+1)*
Recurrence end time								octet (f+2)* octet g*

Table 27 shows examples of Time window contents.

SOR transparent container may include the following table 28 and 29.

8	7	6	5	4	3	2	1
Length of SNPN info								octet u+3 octet u+4
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	LAII	Time Ind	octet u+5
SNPN identity								octet (u+6)* octet (u+14)*
Time validity information								octet (u+15)* octet u1*
Location assistance information								octet (s+1)* octet (q)*

Table 28 shows examples of SNPN information. SNPN information based on table 28 include time validity information of table 29.

8	7	6	5	4	3	2	1
Number of time periods								octet (p+18) or (t+15)
Time period 1								octet (p+19) or (t+16) octet (p+34) or (t+31)
Time period 2								octet (p+35)* or (t+32)* octet (p+50)* or (t+47)*
...								octet (p+51)* or (t+48)* octet (p+2+o16) or (t-1+o16)
Time period o								octet (p+3+o16) or (t+o16) octet (p+18+o16)* or (t+15+o16) = octet s

Table 29 shows examples of Time validity information. Herein, Time period may mean the time period field is coded as the route selection descriptor component value field for "time window type" specified in 3GPP TS 24.526 V18.0.0 table 5.2.1.

8	7	6	5	4	3	2	1
Length of GIN info								octet v+3 octet v+4
0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	0 Spare	LAII	Time Ind	octet v+5
GIN								octet (v+6)* octet (v+14)*
Time validity information								octet (v+15)* octet v1*
Location assistance information								octet (s+1)* octet (q)*

Table 30 shows examples of GIN information.

8	7	6	5	4	3	2	1
Length of CAG-ID with additional information contents								octet x+1
Length of CAG-ID with additional information contents								octet x+2
CAG-ID								octet x+3 octet x+6
0 Spare	SVII	SVII	SVII	SVII	SVII	SVII	TVII	octet x+7
Time validity information								octet (x+8)* octet (x+23)*

Table 31 shows examples of Closed Access Group (CAG)-ID with additional information.

Hereinafter, another example scenario is explained. For example, weekly flee market may be used as an example of the recurrent events.

The SNPN provides a flee market service every Saturday 9AM ~ 6PM from 2023. 03.04 to 2023. 06.24. Total 17 weeks.

The SNPN may provide the flee market service information included in the SoR transparent container in a REGISTRATION ACCEPT message. For example, an AMF of the SNPN may transmit the REGISTRATION ACCEPT message including the SoR transparent container to the UE.

In this example scenario, T1 may be equal to 7 days and T2 may be equal to 9 hours. Or, T1 may be calculated as the remaining time of the start time point of the next service start time.

The network may provide the number of frequencies of the event N, which is equal to 17.

The UE may determine the value of T_start based on the time point receiving SoR information and/or the start time of the first event.

Upon reception of SoR information, e.g., 2023.03.01 9AM, T_start may be calculated as the remaining time until the start time of the first event. In this case, T_start is equal to 3 days.

The UE may calculate the value of T_end to the time duration between the start time point of the first event and the end time point of the last event.

T_end may be calculated as {24 hours * (17 weeks -1) + 9 hours} = 393 hours.

The value of a timer may be stored in a unit of seconds in the UE. For example, the value of T_start may be 269,200.

As another option of the timer design, a timer may consist of the value part and the unit part. For example, the UE may store the associated unit (e.g., day, hour, second) and the value (e.g., 3).

FIG. 14 illustrates an example of second example scenario according to an embodiment of the present disclosure.

In Figure 16, the time point t_x (e.g., t_0, t_1, ..., t_n) represents the time point that a particular event occurs. The time point may be the same if more than one event occurs at the same time. For example, t_0 to t_4, t_n may be defined as the following:

t_0: the UE may receive SoR information to support a localized service in the REGISTRATION ACCEPT message.

For example, the UE may start T_start based on t_0. Herein, t_0 may be a specific time point and T_start may be a timer. For example, the UE may receive SoR information on the time point t_0. The UE may set the value of T_start based on subtracting t_0 from t_1. The UE may start timer T_start.

t_1: the UE may perform network selection to select a particular network providing the intended (localized) service.

For example, the UE may start T1. In this case, the value of T1 may be (t_3) - (t_1).

For example, the UE may start T2.

For example, the UE may send the REGISTRATION REQUEST MESSAGE to register to the selected network to receive the intended service.

t_2: the UE may perform network selection when the UE does not use the intended service any more.

For example, the UE may start T1. In this case, the value of T1 may be (t_3) - (t_2).

For example, the UE may send the REGISTRATION REQUEST MESSAGE to register to the selected network.

t_3: the UE may perform network selection to select a particular network providing the intended service.

For example, the UE may start T1.

For example, the UE may start T2.

For example, the UE may send the REGISTRATION REQUEST MESSAGE to register to the selected network to receive the intended (localized) service.

t_4: the UE may perform network selection when the UE does not use the intended service any more.

t_n: the UE may perform network selection when the UE does not use the intended service any more.

For example, the UE may delete the stored information for the localized service.

After successful network selection, the UE may send the REGISTRATION REQUEST MESSAGE to register to the selected network.

Examples of UE operations according to Figure 16 are expalined as follows.

Step 1 (t_0): The UE may receive a localized service information with recurrent events, described as t_0 (e.g., 2023. 03.01, Wednesday, 9AM).

- The UE may receive the localized service information included in the SoR transparent container in a REGISTRATION ACCEPT message.

- The UE may receive the localized service information via NAS signalling after successful registration.

- The localized service may include a list of SNPN that provides the localized service, the service time to provide localized service in the SNPN, the frequencies of the recurrent events, etc

- Upon reception of the localized service information, the UE may store the localized service information in the UE.

- The UE may determine a number of timers required to provide to the localized service operation. For example, the UE may generate timers T1, T2, and optionally T_start, and/or T_end, and generate a variable N. For example, the UE may generate a timer T_start if the start time point of the first event is not equal to the time point t_0. For example, T_start = t_1 - t_0 (e.g., 3 days). For example, the UE may generate a timer T_end if the network does not provide a parameter N. For example, the UE may generate a variable N if the network provides the frequencies of the recurrent events.

- The UE may start a timer T_start, if available. For example, the UE may adjust the value of T_start to start a SNPN selection procedure in Step 2 slightly before the actual flee market service time (e.g., 9AM). In this way, the UE may use the flee market service on time (e.g., 9AM) after successful selection of or registration to the SNPN.

Step 2 (t_1):

The UE may perform a network selection procedure to search for the network providing the intended localized service, described as t_1 (e.g., 2023. 03.04, Saturday, 9AM), the start time point of the first flee market service in the first week.

- If the UE has started T_start, the time point t_1 may be the time point of expiry of T_start.

- The UE may start a timer T1 (e.g., 7 days, T1 = (t_3) - (t_1)).

- The UE may start a timer T2 (e.g., 9 hours).

Step 3 (t_2):

The UE may perform a network selection procedure to search for other network after use of the localized service ends.

- t_2 may be the time point of expiry of T2.

- t_2 may be the time point that the UE deactivates the SNPN operation mode to not use localized services or SNPN.

- The UE may include the SNPN selected in Step 2 into the forbidden SNPN list until Step 4.

- The UE may start a timer T1 (e.g., T1 = (t_3) - (t_2)), which is the remaining time of the start time point of the next event.

Step 4 (t_3):

The UE may perform a network selection procedure to search for the network providing the intended localized service, described as t_1 (e.g., 2023. 03.11, Saturday, 9AM), the start time point of the second flee market service in the second week.

- The UE may start a timer T1 (e.g., 7 days).

- The UE may start a timer T2 (e.g., 9 hours).

Step 5 (t_4):

- t_4 may be the time point of expiry of T2.

- t_4 may be the time point that the UE deactivates the SNPN operation mode to not use localized services or SNPN.

- The UE may include the SNPN selected in Step 4 into the forbidden SNPN list until Step 5.

- The UE may start a timer T1 (e.g., T1 = (the start time point of the next event start time) - (t_4)), which is the remaining time of the start time point of the next event.

Step 5:

The UE may perform a network selection procedure to search for the network providing the intended localized service.

Step 6 (t_n):

The UE may remove the stored information for the localized service. t_n may be the service end time of the SNPN localized services (e.g., 2023. 06.04, Saturday, 6PM).

Hereinafter, signalling format for transmitting slice informatin including periodic time validity information is explained.

NSSAI time validity information is explained. The purpose of the S-NSSAI time validity information information element is to provide S-NSSAI time validity information of one or more S-NSSAIs to the UE.

The S-NSSAI time validity information information element is coded as shown in Table 32 to Table 36.

The S-NSSAI time validity information information element may include per-S-NSSAI time validity information for maximum 16 S-NSSAIs.

The S-NSSAI time validity information information is a type 4 information element with a minimum length of 23 octets and a maximum length of 257 octets.

8	7	6	5	4	3	2	1
S-NSSAI time validity information information IEI								octet	1
Length of S-NSSAI time validity information contents								octet	2
Per-S-NSSAI time validity information for S-NSSAI 1								octet 3 octet a
Per-S-NSSAI time validity information for S-NSSAI 2								octet a+1* octet b*
...								octet b+1* octet c*
Per-S-NSSAI time validity information for S-NSSAI n								octet c+1* octet d*

Table 32 shows examples of S-NSSAI time validity information information element.

8	7	6	5	4	3	2	1
Length of Per-S-NSSAI location availability information for S-NSSAI								octet	3
S-NSSAI								octet	4 octet e
Per-S-NSSAI time validity information for the S-NSSAI								octet e+1 octet a

Table 33 shows examples of Per-S-NSSAI time validity information for S-NSSAI 1 of Table 32.

8	7	6	5	4	3	2	1
Length of Per-S-NSSAI time validity information for the S-NSSAI								octet e+1
Time window 1								octet e+2 octet f
Time window
2								octet f+1* octet g*
...								octet g+1* octet h*
Time window m								octet h+1* octet i*

Table 34 shows examples of Per-S-NSSAI time validity information for the S-NSSAI in Table 33.

8	7	6	5	4	3	2	1
Length of Time window 1								octet e+2
Start time								octet e+3 octet e+10
Stop time								octet e+11 octet e+18
0 Spare	0 Spare	0 Spare	0 Spare	Recurrence pattern				octet e+19*
Recurrence end time								octet e+20* octet e+27*

Table 35 shows examples of Time window 1 in Table 34.

S-NSSAI (octet 6 to octet e) S-NSSAI value is coded as the length and value part of S-NSSAI information element as specified in subclause　9.11.2.8 starting with the second octet.

Start time (octet e+3 to octet e+10)
The field indicates the time when the network slice identified by the S-NSSAI becomes available (for the first time if octet e+20 is included) and is represented by the number of seconds since 00:00:00 on 1 January 1970 UTC and is encoded as the 64-bit NTP timestamp format defined in IETF　RFC　5905　, where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits.

Stop time (octet e+11 to octet e+18)
The field indicates the time when the network slice identified by the S-NSSAI becomes unavailable (for the first time if octet e+20 is included) and is represented by the number of seconds since 00:00:00 on 1 January 1970 UTC and is encoded as the 64-bit NTP timestamp format defined in IETF　RFC　5905　, where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits.

Recurrence pattern (bit 1 to bit 4 of octet e+19)
Bits
4	3	2	1
0	0	0	0	Everyday
0	0	0	1	Every weekday
0	0	1	0	Every week
0	0	1	1	Every 2 weeks
0	1	0	0	Every month (absolute)
0	1	0	1	Every month (relative)
0	1	1	0	Every quarter (absolute)
0	1	1	1	Every quarter (relative)
1	0	0	0	Every 6 months (absolute)
1	0	0	1	Every 6 months (relative)
All other values are reserved. The recurrence pattern indicates how often the time window is repeated. For example, if the time window starts at 13:00 on Wednesday January 1st 2020 and stops at 13:30 on Wednesday January 1st 2020 and the recurrent pattern is set to: - "Everyday", the time window repeats everyday from 13:00 to 13:30; - "Every week", the time window repeats every Wednesday from 13:00 to 13:30; - "Every month (absolute)", the time window repeats every 1st day of the month from 13:00 to 13:30; and - "Every month (relative)", the time window repeats every month on the first Wednesday from 13:00 to 13:30.
Recurrence end time (octet e+20 to octet e+27)
The field indicates the time when the repetition of the time window ends. If the field is not included and octet e+19 is included in the IE, the time window is repeated indefinitely.The field is represented by the number of seconds since 00:00:00 on 1 January 1970 UTC and is encoded as the 64-bit NTP timestamp format defined in IETF　RFC　5905　, where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits.

Table 36 shows examples of S-NSSAI time validity information information element. For exmaple, Table 36 shows examples of information shown in table 32 to table 35.

FIG. 15 illustrates an example of an operation according to an embodiment of the present disclosure.

In addition, the operation of a UE and a AMF shown in the example of FIG. 15 is only an example. The operation of the UE is not limited by the example of FIG. 15, and the UE and the base station may perform the operations described in various examples of the present specification.

Before step S1501, the UE may transmit a registration request message to the AMF.

In step S1501, the AMF may transmit SoR information to the UE. SoR information may inlcude localized service information from an AMF. The SoR information may be included in a registration accept message trasnmitted from the AMF.

For example, the SoR information includes a plurality of time information related to the localized service information. For example, the plurality of time information include first time information and second time information.

For example, the first time information includes time information related to a start of the recurrent event and/or time information related to an end of the recurrent event. The second time information includes time information related to a periodicity of the recurrent event and/or time information related to an duration of the recurrent event.

In step S1502, the UE may select a network. For example, the UE may perform SNPN slelection procedure.

The SNPN selection procedure may be performed based on the plurality of time information, based on that the localized service information is for a recurrent event. For example, the SNPN selction is performed based on at least one timer based on the plurality of time information.

For example, the at least one timer based on the plurality of time information is used, until the SoR information is deleted after the recurrent event ends

According to an embodiments of the present disclosure, the UE may store time information for localized services. The UE may store it in the MT of the UE. Two or more time information fields are associated with each other. The UE may start the first timer for the localized service. The UE may start the second timer for the localized service in the MT upon expiry of the first timer. The UE may re-start the first timer for the localized service. The UE may perform the corresponding action upon expiry of the second timer.

The present specification may have various effects.

For example, SoR information including specific service time information that is repeatedly supported by the network can be transmitted to the UE. The UE can perform network selection according to the service time for identifying recurrent events without updating the SoR information. This avoids UE power consumption to receive exccessive signalling for SoR information update .

The effects that may be obtained from the specific examples of this disclosure are not limited to those listed above. For example, there may be a variety of technical effects that a person having ordinary skill in the related art may understand or infer from this disclosure. Accordingly, the specific effects of the present disclosure are not limited to those expressly set forth herein, but may include a variety of effects that may be understood or inferred from the technical features of the present disclosure.

For reference, the operation of the terminal (e.g., UE) described in the present specification may be implemented by the apparatus of FIGS. 1 to 4 described above. For example, the terminal (e.g., UE) may be the first device 100 or the second device 200 of FIG. 2. For example, an operation of a terminal (e.g., UE) described herein may be processed by one or

more processors

102 or 202 . The operation of the terminal described herein may be stored in one or

more memories

104 or 204 in the form of an instruction/program (e.g., instruction, executable code) executable by one or

more processors

102 or 202 . One or

more processors

102 or 202 control one or

more memories

104 or 204 and one or

more transceivers

105 or 206, and may perform the operation of the terminal (e.g., UE) described herein by executing instructions/programs stored in one or

more memories

104 or 204.

In addition, instructions for performing an operation of a terminal (e.g., UE) described in the present disclosure of the present specification may be stored in a non-volatile computer-readable storage medium in which it is recorded. The storage medium may be included in one or

more memories

104 or 204 . And, the instructions recorded in the storage medium may be executed by one or

more processors

102 or 202 to perform the operation of the terminal (e.g., UE) described in the present disclosure of the present specification.

For reference, the operation of a network node (e.g., AMF, SMF, UPF, SOR-AF, UDM, etc.) or base station (e.g., NG-RAN, gNB, eNB, RAN, E-UTRAN etc.) described herein may be implemented by the apparatus of FIGS. 1 to 3 to be described below. For example, a network node or a base station may be the first device 100 of FIG.2 or the second device 200 of FIG.2. For example, the operation of a network node or base station described herein may be processed by one or

more processors

102 or 202. The operation of the terminal described herein may be stored in one or

more memories

more processors

102 or 202. One or

more processors

102 or 202 may perform the operation of a network node or a base station described herein, by controlling one or

more memories

104 or 204 and one or

more transceivers

106 or 206 and executing instructions/programs stored in one or

more memories

104 or 204.

In addition, instructions for performing the operation of the network node or base station described in the present disclosure of the present specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium. The storage medium may be included in one or

more memories

104 or 204. And, the instructions recorded in the storage medium are executed by one or

more processors

102 or 202, so that the operations of a network node or base station are performed.

In the above, preferred embodiments have been exemplarily described, but the present disclosure of the present specification is not limited to such specific embodiments, and thus, modifications, changes, or may be improved.

In the exemplary system described above, the methods are described on the basis of a flowchart as a series of steps or blocks, but are not limited to the order of the steps described, some steps may occur in a different order or concurrent with other steps as described above. In addition, those skilled in the art will understand that the steps shown in the flowchart are not exclusive and that other steps may be included or that one or more steps of the flowchart may be deleted without affecting the scope of rights.

The claims described herein may be combined in various ways. For example, the technical features of the method claims of the present specification may be combined and implemented as an apparatus, and the technical features of the apparatus claims of the present specification may be combined and implemented as a method. In addition, the technical features of the method claim of the present specification and the technical features of the apparatus claim may be combined to be implemented as an apparatus, and the technical features of the method claim of the present specification and the technical features of the apparatus claim may be combined and implemented as a method.

Claims

A method for performing communication, the method performed by a User Equipment (UE) and comprising:

receiving Steering of Roaming (SoR) information including localized service information from an AMF; and

selecting a network based on the SoR information,

wherein the SoR information includes a plurality of time information related to the localized service information, and

wherein the selecting is performed based on the plurality of time information, based on that the localized service information is for a recurrent event.
The method of claim 1, the selecting is performed based on at least one timer based on the plurality of time information.
The method of claim 1 or claim 2,

wherein the plurality of time information include first time information and second time information.
The method of claim 3,

wherein the first time information includes time information related to a start of the recurrent event and/or time information related to an end of the recurrent event.
The method of claim 3,

wherein the second time information includes time information related to a periodicity of the recurrent event and/or time information related to a duration of the recurrent event.
The method of one of any preceding claims,

wherein at least one timer based on the plurality of time information is used, until the SoR information is deleted after the recurrent event ends.
The method of one of any preceding claims, further comprising:

transmitting a registration request message to the AMF, and

wherein the SoR information is included in a registration accept message trasnmitted from the AMF.
The method of one of any preceding claims, further comprising:

wherein the SoR information is included in a Downlink (DL) Non Access Stratum (NAS) message trasnmitted from the AMF.
The method of one of any preceding claims,

wherein the netowkr is a Standalone Non Public Network (SNPN).
A user equipment (UE) configured to operate in a wireless communication system, the UE comprising:

at least one transceiver;

at least one processor; and

at least one memory that stores instructions and is operably electrically connectable with the at least one processor,

wherein operations performed based on the instructions being executed by the at least one processor include method of claims 1 to 9.
An apparatus performing communication, comprising:

at least one processor; and

at least one memory storing instructions, operatively electrically coupled to the at least one processor, wherein the instructions are executed by the at least one processor to perform operations comprising method of claims 1 to 9.
A non-transitory computer readable storage medium recording instructions,

wherein the instructions, when executed by one or more processors, causing the one or more processors to perform operations compirsing method of claims 1 to 9.
A method for performing communication, the method performed by an Access and Mobility Function (AMF) and comprising:

receiving a registration request message from a User Equipment (UE); and

transmitting a registration accept messag to the UE,

wherein the registration accept message includes Steering of Roaming (SoR) information including localized service information,

wherein the SoR information is used by the UE to select a network,

wherein the SoR information includes a plurality of time information related to the localized service information, and

wherein the selecting is performed based on the plurality of time information, based on that the localized service information is for a recurrent event.
The method of claim 13,

wherein the plurality of time information include first time information and second time information.
The method of claim 14,

wherein the first time information includes time information related to a start of the recurrent event and/or time information related to an end of the recurrent event.
The method of claim 14,

wherein the second time information includes time information related to a periodicity of the recurrent event and/or time information related to an duration of the recurrent event.
The method of one of claim 13 to claim 16,

wherein the network is a Standalone Non Public Network (SNPN).
An Access and Mobility Function (AMF)configured to operate in a wireless communication system, the base station comprising:

at least one transceiver;

at least one processor; and

at least one memory that stores instructions and is operably electrically connectable with the at least one processor,

wherein operations performed based on the instructions being executed by the at least one processor include method of claim 13 to claim 17.