CN116530116A - Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials - Google Patents

Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials Download PDF

Info

Publication number
CN116530116A
CN116530116A CN202180080788.XA CN202180080788A CN116530116A CN 116530116 A CN116530116 A CN 116530116A CN 202180080788 A CN202180080788 A CN 202180080788A CN 116530116 A CN116530116 A CN 116530116A
Authority
CN
China
Prior art keywords
network
wtru
lts
service
temporary
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180080788.XA
Other languages
Chinese (zh)
Inventor
王关州
萨阿德·艾哈迈德
阿莱克·布鲁西洛夫斯基
尤利西斯·奥尔韦拉-埃尔南德斯
时晓岩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Patent Holdings Inc
Original Assignee
InterDigital Patent Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Patent Holdings Inc filed Critical InterDigital Patent Holdings Inc
Priority claimed from PCT/US2021/057734 external-priority patent/WO2022094469A1/en
Publication of CN116530116A publication Critical patent/CN116530116A/en
Pending legal-status Critical Current

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

A method implemented in a wireless transmit/receive unit (WTRU) of provisioning the WTRU for communication in a temporary local network, the method comprising transmitting information to a loading network regarding the WTRU's ability to communicate with the temporary local network. Configuration information is received from the loading network to preset the temporary local network. A message is received from the loading network using the received configuration information, the message identifying a preset configuration for use by the WTRU with the temporary home network. A message is sent to the temporary local network using the preset configuration.

Description

Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials
Cross Reference to Related Applications
The present application claims the benefit of U.S. provisional patent application No. 63/108,539, filed 11/2/2020, and U.S. provisional patent application No. 63/230,383, filed 8/2021, the disclosures of which are incorporated herein by reference in their entirety.
Background
In some cases, a small cellular network may be deployed to provide services for local users within a certain area. For example, a temporary non-public cellular network may be established to provide streaming video services to spectators in live concerts or football matches. As another example, where people are gathered at airports, shopping centers, campuses, and the like, a small cellular network may be deployed to provide localized services, such as commercial advertising at a shopping center or on-demand services at a movie theater. These cellular networks provide services with two basic features: i) Services are localized services in the sense that they relate to activities and/or events in a certain location or area, and they are typically provided only to users located at that location or within that area; and ii) the user will not typically use these services on a regular basis, but will likely use these services on an as-needed or temporary basis. Thus, such services may be referred to as Localized Temporary Services (LTS).
The cellular network that provides LTS is referred to as an LTS managed network. The hosting network may be a temporary network, meaning that it may be temporarily established for an activity and then torn down after the activity has ended; however, the hosted network may also be a long-term network, such as a network deployed in a shopping mall or university campus.
The hosted network may be a non-public network (NPN) or may be part of a Public Land Mobile Network (PLMN) (e.g., created using network slices within the PLMN, i.e., public Network Integration (PNI) -NPN). The operator of the hosting network may be a PLMN operator (even if the hosting network itself is an NPN) or an NPN operator. The service may be provided by a Service Provider (SP), which may be the hosting network operator itself or a third party SP.
Fig. 2A-2C illustrate various deployment possibilities for LTS managed networks. In fig. 2A, the hosting network is NPN and is operated by PLMN operators, while the services are provided by third party SPs. In fig. 2B, the managed network is NPN and is operated by a NPN operator different from the PLMN operator. The service provider may be the NPN operator itself or may be a third party SP. In fig. 2C, the hosting network is PNI-NPN and is operated by the same PLMN operator, while the service is provided by a third party SP.
An important aspect of LTS is that potential service users do not have subscriptions or credentials for accessing the temporary hosted network. Nor any configuration for discovering or selecting a managed network or for establishing a connection in a network. This aspect also distinguishes LTS from other local services provided within the PLMN, such as a local data network (LADN) defined in 3 GPP.
Disclosure of Invention
In one aspect, the present principles relate to a method implemented in a wireless transmit/receive unit (WTRU) of provisioning the WTRU for communication in a temporary local network, the method comprising: transmitting information about the WTRU's ability to interact with the temporary local network to the loading network; receiving configuration information from the loading network to preset the temporary local network; receiving a message from the loading network using the received configuration information, the message identifying a preset configuration for use by the WTRU with the temporary local network; and interacting with the temporary local network using the preset configuration.
In another aspect, the present principles relate to a wireless transmit/receive unit (WTRU) including: a memory configured to store program code instructions; and at least one hardware processor configured to execute the program code instructions to: transmitting information about the WTRU's ability to interact with the temporary local network to the loading network; receiving configuration information from the loading network to preset the temporary local network; receiving a message from the loading network using the received configuration information, the message identifying a preset configuration for use by the WTRU with the temporary local network; and interacting with the temporary local network using the preset configuration.
In yet another aspect, the present principles relate to a method performed by a network function in a first network, the method comprising: upon detecting a subscription request event from a wireless transmit/receive unit (WTRU), monitoring a second network for a subscription request event; creating temporary credentials for the WTRU; and communicating temporary credentials of the WTRU to the WTRU.
In yet another aspect, the present principles relate to a network function including: a memory configured to store program code instructions; and at least one processor configured to execute the program code instructions to: monitoring a subscription request event in a second network in a first network upon detecting a subscription request event from a wireless transmit/receive unit (WTRU); creating temporary credentials for the WTRU; and communicating temporary credentials of the WTRU to the WTRU.
Drawings
In addition, like reference numerals in the drawings denote like elements, and wherein:
FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;
fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A according to one embodiment;
Fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;
fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A according to one embodiment;
FIGS. 2A-2C illustrate various deployment possibilities for LTS managed networks;
FIG. 3 illustrates a high-level network architecture for presetting LTS-hosted network credentials through network opening functionality according to one embodiment;
FIG. 4 illustrates a control plane based method for LTS subscription request event triggering and reporting, according to one embodiment;
5A-5D illustrate a method for presetting LTS escrow network credentials to a UE over a network open framework in accordance with one embodiment;
fig. 6 illustrates a method for accessing local temporary services based on a LADN, according to one embodiment;
FIG. 7 illustrates a method for hosting network credentials through a PDU session establishment Cheng Yuzhi LTS, according to one embodiment;
FIG. 8 illustrates a method for provisioning LTS escrow network credentials with a credential server and a ticket server, according to one embodiment;
Fig. 9 illustrates automatic network access triggering using PLMN location and application trigger services according to one embodiment; and is also provided with
Fig. 10 is a signal flowchart illustrating a process for remotely provisioning a UE according to an exemplary embodiment.
Detailed Description
Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter Bank Multicarrier (FBMC), and the like.
As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN) 104, a Core Network (CN) 106, a Public Switched Telephone Network (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.
Communication system 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, gnbs, NR node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
Base station 114a may be part of RAN 104 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio Frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).
More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or high speed Uplink (UL) packet access (HSUPA).
In one embodiment, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-APro) to establish the air interface 116.
In one embodiment, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as NR radio access, which may use a new air interface (NR) to establish the air interface 116.
In one embodiment, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., enbs and gnbs).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the internet 110 through the CN 106.
The RAN 104 may communicate with a CN 106, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that RAN 104 and/or CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, wiMAX, E-UTRA, or WiFi radio technology.
The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Other networks 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the other network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE 802 radio technology.
Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a chipset 136 for a positioning system such as a Global Positioning System (GPS), and/or other elements 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a in fig. 1A) over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In one embodiment, the transmit/receive element 122 may be an emitter/detector configured to emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
Although the transmit/receive element 122 is depicted as a single element in fig. 1B, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs (such as NR and IEEE 802.11).
The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124 and/or the display/touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.
The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.
The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.
The processor 118 may also be coupled to other elements 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, element 138 may include an accelerometer, an electronic compass, a satellite transceiver digital cameras (for photographs and/or video) Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. Element 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; a geographic position sensor; altimeter, optical sensor, touch sensor, magnetometer, barometer, Gesture sensors, biometric sensors, and/or humidity sensors.
WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit for reducing and/or substantially eliminating self-interference by hardware (e.g., choke) or by signal processing by a processor (e.g., a separate processor (not shown) or by processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) or downlink (e.g., for reception)).
Fig. 1C is a system diagram illustrating a RAN 104 and a CN 106 according to one embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using an E-UTRA radio technology. RAN 104 may also communicate with CN 106.
RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In an embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or to receive wireless signals from the WTRU 102a, for example.
Each of the evolved node bs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.
The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
The MME 162 may be connected to each of the evolved node bs 162a, 162B, 162c in the RAN 104 through an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.
SGW 164 may connect to each of the evolved node bs 160a, 160B, 160c in RAN 104 through an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.
The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (such as the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and legacy landline communication devices. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers.
Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).
In representative embodiments, the other network 112 may be a WLAN.
A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a width dynamically set by signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.
High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, by combining a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.
Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be sent to a Medium Access Control (MAC).
The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).
WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA (supporting only 1MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and possibly available.
The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
Fig. 1D is a system diagram illustrating a RAN 113 and a CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over an air interface 116. RAN 113 may also communicate with CN 115.
RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 113 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, the gnbs 180a, 180b, 180c may utilize beamforming to transmit signals to and/or receive signals from the WTRUs 102a, 102b, 102 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit a plurality of component carriers (not shown) to the WTRU 102 a. A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).
The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from one transmission to another, from one cell to another, and/or from one portion of the wireless transmission spectrum to another. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).
The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102C may communicate with the gnbs 180a, 180B, 180C while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160C in fig. 1C). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.
Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slices, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.
The CN 115 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
AMFs 182a, 182b may be connected to one or more of gNB 180a, 180b, 180c in RAN 113 via an N2 interface and may function as a control node. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, and so on. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency (URLLC) access, services relying on enhanced large-scale mobile broadband (eMBB) access, services for MTC access, etc. AMF 162 may provide control plane functionality for switching between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi.
The SMFs 183a, 183b may be connected to AMFs 182a, 182b in the CN 115 through an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN 115 via an N4 interface. SMFs 183a, 183b may select and control UPFs 184a, 184b and configure traffic routing through UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.
UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 through an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local Data Networks (DNs) 185a, 185b through the UPFs 184a, 184b through an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.
In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-d, base stations 114a-B, evolved node bs 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DN 185a-B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.
The simulation device may be designed to enable one or more tests of other devices in a laboratory environment and/or an operator network environment. For example, the one or more emulation devices can perform one or more or all of the functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices can perform one or more functions or all functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and/or may perform testing using over-the-air wireless communications.
The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test laboratory and/or a test scenario in a non-deployed (e.g., test) wired and/or wireless communication network in order to enable testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and/or wireless communication through RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and/or receive data.
Detailed Description
If the service network of the potential LTS user has a business relationship or service agreement with the LTS hosted network, the potential user should be able to receive LTS service advertisements through the user's serving PLMN. For example, the method for multimedia broadcast/multicast service (MBMS) service announcement defined in TS 23.246 may be reused or enhanced to deliver LTS advertisements to potential users. The user may also receive LTS service information from the serving PLMN through system information broadcast or non-access stratum (NAS) signaling. In addition, new technologies such as 5G multicast broadcast service (5 MBS) may also be used for LTS service advertising.
After obtaining the LTS information, the potential user may not be able to access the service immediately. LTS managed networks are typically non-public or temporary networks where potential users do not have a subscription or network selection configuration. In order for a user to access hosted networks and services, a UE needs i) basic credentials to access the hosted networks, and ii) to be able to automatically select the hosted networks, both of which will be described in the following paragraphs.
The hosting network may be a temporary network without subscribed users and will encourage more users to access the service, but this may lead to potential abuse due to the fact that it does not have basic security checks. A hosted network may benefit from a mechanism that allows only legitimate users to access, as well as the ability to identify a service and charge the user for that service. From the perspective of potential service users, the UE needs to be able to obtain basic credentials for accessing the temporary hosted network.
The potential user may obtain the network identifier of the hosted network through the service advertisement. Theoretically, they can manually choose to host a network to access a service. However, the process of manually selecting a network may reduce the user's willingness to use the service. On the other hand, if the UE has sufficient coverage for its serving PLMN, automatic selection of a network for which the UE does not have subscription or configuration cannot be triggered according to existing specifications.
Furthermore, the UE may utilize the loading and remote provisioning mechanisms introduced in 3gpp Rel 17 to obtain temporary subscriptions and credentials for the hosted network. If the PLMN is used as the loading network, the data network name/single network slice selection assistance information (DNN/S-NSSAI) for remote provisioning is part of the subscription data of the UE. Further, a preset server (PVS) address (e.g., PVS Fully Qualified Domain Name (FQDN) or PVS Internet Protocol (IP) address) is configured in the network (e.g., in SMF) according to DNN/S-NSSAI and may be sent to the UE, e.g., during a PDU session establishment procedure. However, if the remote preset is for an LTS network/service, the subscription data of the UE will not have a DNN/S-nsai configuration for the target LTS network, as the target service/network is dynamically selected. Thus, the loading network (i.e., PLMN) will not have every DNN/S-NSSAI configuration with a preset server address.
A similar problem exists for the case where the UE uses a separate non-public network (SNPN) as the loading network, where the SNPN does not know which PVS address should be provided to the UE for remote provisioning. Furthermore, it may not be known how the UE selects the SNPN for loading and remotely presetting the target LTS network.
Accordingly, there is a need for corresponding methods, techniques, apparatus and means to enable a UE to acquire a remote preset configuration (e.g., PVS address) and/or select a SNPN for loading and remote presetting a target LTS network if it uses a PLMN or SNPN as the loading network.
For all of the reasons discussed above, various methods, devices, techniques, and means for temporarily provisioning LTS-hosted network credentials are presented in the following discussion.
Presetting LTS hosted network credentials through network opening functionality
Fig. 3 illustrates a high-level network architecture for presetting LTS-hosted network credentials by a network open function (NEF) 308 (e.g., a network open framework), according to one embodiment. An Application Function (AF) 304 in the LTS-hosting network 302 monitors LTS subscription request events in the PLMN 310 through the NEF 308 of the PLMN. When such an event is detected from a particular service user (e.g., UE or WTRU) 312, the AF 304 in the hosted network 302, along with the preset server/database 306 in the hosted network 302, creates temporary credentials and other configuration information for the UE and communicates these credentials and/or configuration information to the respective UE 312 through the PLMN network open framework.
To achieve this, the network element performs certain tasks:
1) AF 304 in hosting network 302 subscribes to "LTS subscription request" events in PLMN 310 through NEF 308.
2) The LTS service subscriber 312 in the PLMN 310, having received the LTS service advertisement and agreeing to use the service, submits an LTS subscription request via network signaling.
3) The network function (e.g., AMF or SMF) in PLMN 310 detects the "LTS subscription request" event and reports the event to NEF 308, which in turn reports the event back to AF 304 in managed network 302.
4) The AF 304 in the hosted network 302, along with the provisioning server 306 in the hosted network 302, creates temporary credentials and other configuration information for the UE 312 that has requested LTS subscription, and passes this information to the UE 312 through the NEF 308 in the PLMN 310.
These steps will now be described in detail.
LTS subscription request event monitoring
An AF in the managed network may Subscribe to an "LTS subscription request" event in the PLMN using nnef_eventExponsure_substrice provided by the PLMN NEF. A new event ID may be created for the "LTS subscription request" event. In addition to typical parameters for subscribing to event reports (such as event filtering information, event report targets, etc.), the AF may also provide one or more of the following items of information in the event subscription request:
LTS service name: LTS services provided by the managed network are identified. If the service name indicated in the LTS subscription request of the user matches the service name in the event subscription request, the event may be triggered and may be associated with a target event report receiver (i.e., a hosted network).
Network identifier of the managed network: for example, if the hosted network is a standalone NPN (S-NPN), the PLMN ID and the network ID of the S-NPN may be provided. If the PLMN is associated with multiple LTS-hosted networks, the PLMN may determine which LTS-hosted network should receive the event report based on the network identifier indicated in the LTS subscription request of the user.
IP address/port number corresponding to internet URL: a user may initiate an LTS subscription request through a user plane in the PLMN to an internet URL already provided in the service advertisement, for example by sending an HTTP request to the URL. The UPF function in the PLMN may be configured by the SMF to check the destination IP address/port number of the internet traffic packet and if the destination IP address/port number matches the configured IP address/port number, the UPF may report it to the SMF.
LTS service area: since LTS is typically available in a limited area, event monitoring may also be limited to a corresponding area in the PLMN. The PLMN may map the LTS service area to a corresponding area in the PLMN, such as a tracking area list, and configure only the network functions (e.g., AMFs) serving that area for event monitoring.
Maximum allowed subscription number: as a temporary network, which may have a smaller scale (e.g., coverage area), LTS-hosted networks may have limited capacity to accommodate users, e.g., no more than a certain number of users. It can thus set a subscriber number limit for each PLMN with which it has a service relationship. When the subscription request or preset has reached a maximum number, the PLMN may cease reporting new subscription request events to the hosting network. The AF may also use the NEF service to dynamically update the number.
When the NEF receives an event subscription request, if the request can be authorized, the NEF subscribes to the event with a Unified Data Management (UDM) by sending a Nudm_EventExposure_Subscriber request. The NEF may map the LTS service area to a certain PLMN area (e.g., TA list) and include it in the request. The UDM determines the network functions (e.g., AMF or SMF) that serve the area and invokes event open services for those network functions. If user plane event detection is to be used, i.e., event detection by matching the IP address/port number of the internet traffic (e.g., HTTP request to URL), the SMF may further determine the related PDU session and configure the service UPF to monitor UP packets.
LTS subscription request event triggering and reporting
When a potential LTS user receives an LTS service advertisement and agrees to use the service, it may trigger the UE to submit an LTS subscription request in the PLMN using a Control Plane (CP) based approach or a User Plane (UP) based approach.
Fig. 4 shows an example of a CP-based method. UE 402 submits an LTS subscription request using network signaling (e.g., NAS signaling). The UE 402 may submit the LTS subscription request in a new NAS procedure, for example, by sending a NAS LTS subscription request message in step S408. The LTS subscription request message may include:
LTS service name or code that identifies the LTS that the user wishes to access. The LTS service name may have been received from the LTS service advertisement/notification and stored in the UE.
A network identifier of the hosted network. For example, if the hosted network is a standalone NPN, the PLMN ID and the network ID of the S-NPN may be included. The hosted network identifier may have been received from the LTS service advertisement/notification and stored in the UE.
LTS network slice or S-NSSAI associated with LTS. For example, there may be a business agreement between the managed network and a Mobile Network Operator (MNO) that assigns dedicated network slices for LTSs.
If the serving network function (e.g., AMF) in the PLMN has been configured to monitor for LTS subscription request events and the LTS service name and/or managed network identifier in the LTS subscription request matches the event monitoring configuration, then in step S410 the LTS subscription event is detected and reported back to the NEF (e.g., in a namf_eventExposure_notify message). In step S412, if the event report has been reported to the NEF and, in turn, to the hosting network, the network may provide a response to the UE that the LTS subscription request has been successfully submitted (e.g., a NAS LTS subscription response message); alternatively, if an event report is not sent for some reason, a response is provided that the request has failed.
Alternatively, the LTS subscription request may be submitted as part of a registration update, service request, or other NAS procedure. For example, the indication of the above-described LTS subscription request and a container carrying LTS subscription request information may be included in a registration update request or service request message.
In an UP-based approach, the UE may have obtained an internet URL from the service advertisement/notification and may send a request (e.g., an HTTP request) to the URL over some PDU session in the PLMN. The service SMF that has been configured to monitor LTS subscription events may have configured the service UPF to inspect the packet, for example, to inspect the IP header of the packet. If the information in the IP header (e.g., IP address/port number) matches the monitoring configuration, the UPF may report it to the SMF. The UPF may also perform deep packet inspection to retrieve and report other subscription related information (e.g., service names) in the HTTP request to the SMF. The SMF then reports the LTS subscription event back to the NEF.
When an LTS subscription event is detected by a CP-based method or an UP-based method, the NEF may augment the event report with a General Public Subscription Identifier (GPSI) of the UE (e.g., MSIDN or external identifier) and an identifier of the home PLMN and/or serving PLMN, and send the event report to the AF in the managed network.
Temporary credential creation and delivery
When the hosted network receives an LTS subscription request from a serving user (e.g., WTRU or other UE), a provisioning server 306 in the hosted network 302 may assign a temporary UE identifier and a credential or token associated with the temporary UE identifier. Additionally, the temporary UE identifier and token may be associated with a particular network slice. Slice specific authentication may be used to enable that particular UE to access LTSs in the managed network. It may also set a temporary UE identifier and a credential/token lifecycle. The lifetime of the temporary UE identifier/credential may also indicate the period of time that LTS services are available. The managed network may also maintain a binding between the GPSI of the UE and the temporary UE identifier for billing purposes.
The AF may invoke the NEF service (e.g., nnef_parameter provisioning_create) of the PLMN to communicate the UE temporary identifier and credential and the managed network identifier associated with the credential to the UE through the PLMN. The hosted network may also provide other necessary configuration information for the LTS in the hosted network to the UE, such as a private Data Network Name (DNN), network slice information, a closed access group identifier (in the case where the hosted network is a PNI-NPN), and so on. The PLMN may provide additional information to the UE, such as a PLMN area corresponding to the LTS service area.
Referring to fig. 5A-5D (a subset of entities is shown in each figure), a method for presetting LTS-hosted network credentials to a UE over a network open framework is shown, according to one embodiment.
In step S502, AF 517 in the hosted network subscribes to "LTS subscription request" event notifications in the PLMN by sending a request (e.g., nnef_eventExponsure_subscore request with information about subscription event and service name) to NEF 515. AF 517 may provide event related information in the request, such as LTS service name, hosting network identifier, LTS service area, etc.
In step S504, the NEF 515 subscribes to event notifications by sending a request (e.g., a nudm_eventExposure_substrice request) to the UDM 513. The NEF 515 may map the LTS service area to a certain PLMN area, such as a TA list, and provide it to the UDM 513.
In step S506, the UDM 513 determines the serving network function based on the trigger pattern of the event and the relevant PLMN area. If the corresponding network function is AMF 507, in step S508a, UDM 513 subscribes to event notifications, for example, by sending a namf_eventExponsure_subscore request (including LTS subscription event, service name and IP address/port) to service AMF 507. However, if the corresponding network function is SMF 509, in step S508b, UDM 513 subscribes to the event notification by sending an nsmf_eventExposure_substrice request (e.g., including LTS subscription event, service name, IP address/port, etc.) to service SMF 509; in the case where event detection is based on UP packet inspection, in step S510b, the SMF may configure the UPF 511 with IP header information to be matched for event detection, i.e., for IP packet inspection.
In step S512 (see fig. 5B), the UE 503 receives the LTS service advertisement (e.g., via SMS, web page, etc.), and may notify the service user 501.
In step S514, LTS service information such as LTS service name, managed network identifier, etc. may be stored in the UE 503.
In step S516, the UE 503 receives user consent regarding the use of the service. The user consent may trigger the UE 503 to initiate an LTS subscription request in the PLMN using either the CP-based method (in steps S518a and S520 a) or the UP-based method (in steps S518b, S520b and S522 b).
CP-based method. In step S518a, the UE 503 may send a NAS service request message to the service AMF 507. The service request message may include an LTS subscription request indication and an LTS information container. In step S520a, in the case where the LTS information (service name, network identifier) in the service request message matches the event monitoring configuration received by the AMF 507 in step S508a, the AMF 507 considers that an LTS subscription event has been detected and notifies the NEF 515 of the event by transmitting namf_eventExposure_notify to the NEF 515.
UP-based method. In step S518b (see fig. 5C), the UE 503 may send an HTTP request to the URL provided in the service advertisement. The HTTP request may be sent over a PDU session in the PLMN. In step S520b, in the case where the IP header information of the packet matches the IP header information configured in step S510b, the UPF 511 reports it to the SMF 509.UPF 511 can also retrieve it in HTTP requests through deep packet inspection His information and sends it to the SMF 509. In step S522b, the SMF 509 notifies the NEF 515 of the LTS subscription event by transmitting nsmf_eventExposure_notify (e.g., including an identifier of the event) to the NEF 515.
In step S524, the NEF 515 forwards the event notification from the AMF 507 or SMF 509 to the AF 517 in the hosted network. The NEF 515 may enhance event notification (e.g., identifier of LTS subscription event) using additional information such as GPSI, home PLMN, and serving PLMN identifiers of the UE.
In step S526 (see fig. 5D), AF 517 assigns a temporary UE identifier with a preset server (not shown here) in the hosting network and creates credentials for UE 503.
In step S528, the AF 517 invokes the NEF service to pass the credential and associated network identifier to the UE 503 by sending an nnef_parameter provisioning_create (e.g., including GPSI and LTS credentials) request to the NEF 515.
In step S530, the AF 517 may request that the UDM 513 store LTS credentials and other related parameters as part of the UE user information by sending a nudm_parameter provision_create request to the UDM 513.
In step S532, the UDM 513 may initiate a UE parameter update (i.e., configuration) procedure to pass LTS credentials and other related parameters to the UE 503. The UE 503 stores the data and may start a timer to monitor the validity of the data according to a lifecycle associated with the data.
In step S534, upon receiving the LTS credential and configuration information, the UE 503 may indicate (i.e., notify) to the service user 501 that the LTS service subscription was successful.
The UE may discard the credential locally when the UE determines that the credential has expired based on a lifecycle associated with the received LTS credential. The UDM in the PLMN may also discard LTS credentials and other related parameters when the LTS credentials have expired or when an AF request by the LTS hosting network.
Access to local services based on LADN
When the UE enters an area (e.g., tracking area or registration area) where service is being provided, the UE may be notified of new or temporary service, for example, by having the network send new local data network (LADN) information to the UE when the UE enters the area. The network may use a UE Configuration Update (UCU) procedure to send the LADN information. The LADN information may include information about a LADN DNN from an LTS managed network. The network may also provide new UE routing policy (UASP) rules to the UE to connect to the LADN from the managed network. In the event that the UE decides to use a local or temporary service from the LTS-hosted network based on the received information, it may trigger the process described in connection with fig. 5A-5D (see, e.g., step S516-step S534) to receive temporary credentials of the LTS-hosted network (using a CP-based approach or an UP-based approach). The UE may then connect to the LTS-hosted network and establish a LADN PDU session to receive access to the local temporary service.
Fig. 6 illustrates accessing local temporary services based on a LADN according to one embodiment.
In step S602, the AMF in the PLMN 603 detects that the UE 601 has entered an area with local temporary service. The detection may be based on a current UE tracking area or registration area.
In step S604, the AMF in the PLMN 603 initiates the UCU procedure. The AMF may include LADN information of the LTS network, urs of the LTS network in a UCU message to the UE 601. The AMF may also include an indication that the UE 601 is performing a registration procedure.
In step S606, the UE 601 may need to access the LTS service. Based on the newly received UHSP rules, the UE 601 decides to use the LADN DN for the LTS network.
In step S608, the UE 601 requests temporary credentials of the LTS network, as described in fig. 5A to 5D (e.g., step S516 to step S534).
After receiving the temporary credentials, the UE 601 registers with the LTS network and establishes a LADN PDU session to receive access to LTS services in step S610.
Network credentials hosted by Cheng Yuzhi LTS through PDU session establishment
Referring to fig. 7, in one embodiment, a UE initiates a PDU session establishment procedure to request temporary credentials for an LTS service. The data network name for PDU session establishment may be a common DNN for all LTS services; instead of indicating the DNN, the UE may rely on the network to select the DNN corresponding to the LTS service that the UE wishes to access. In step S702, the UE receives an LTS service advertisement (e.g., via SMS, web page, etc.) and may notify the service user; and in step S704, LTS service information such as LTS service name, managed network identifier, etc. may be stored in the UE. In step S706, the UE may include an LTS subscription request and an LTS information container in the PDU session establishment request message. After receiving the message, the SMF identifies a target server (e.g., a preset server) in the hosted network from the provided LTS information (e.g., LTS service name, hosted network identifier, etc.). The mapping between LTS information and target preset server addresses may have been configured in the SMF. Then, in step S708, the SMF establishes an N4 session with the UPF, and establishes a data connection with a preset server in the hosting network through the UPF. The SMF may then communicate with the provisioning server, for example, by calling an API provided by the provisioning server, to retrieve temporary credentials for accessing the hosted network in step S710. The SMF may provide the UE identity (e.g., GPSI) and other information to a provisioning server.
After the SMF has received the temporary credentials, it may forward them to the UE in a PDU session establishment accept or reject message in step S712. Since the purpose of the PDU session establishment request is to retrieve the LTS credential, the SMF may not allocate real UP resources for the UE.
Presetting LTS escrow network credentials by a credential server and ticket server
Fig. 8 illustrates a method for provisioning LTS-hosted network credentials by a credential server and ticket server, according to one embodiment.
Assume that the UE 801 and ticket server 805 have a pre-established security context.
In step S802, the UE 801 requests an access ticket (AV) from a ticket server (VS) 803.
In step S804, VS 803 verifies the credentials of UE 801 and sends back encrypted service credentials (SV), which may include AV, ticket Server (TS) identifier, and identifier of LTS hosting network 807.
In step S806, the UE 801 stores AV; when the AV expires, the local UE session manager may request another SV (which may be transparent to the user).
When the UE 801 requests access to LTS or other resources on the network:
in step S808, the UE 801 transmits the current AV to the TS 805 (i.e., the TS corresponding to the TS identifier) having the LTS-managed network ID (or the regular expression having the wild card) that the UE 801 wishes to access.
In step S810, the TS 805 verifies that the AV is received from the UE 801, and the UE 801 is authorized to access the required network; alternatively or additionally, the TS 805 queries a list of networks to which the UE 801 is authorized to access.
In step S812, the TS 805 replies to the UE 801 with a list of networks/resources having associated Access Ticket (AT) and valid session keys for the networks/resources (e.g., LTS-hosted network identifier, AT for LTS-hosted network, and session key).
In step S814, the TS 805 forwards the AT along with the session key to the LTS hosting network 807.
In step S816, the UE 801 forwards the AT to the required network (LTS-hosted network 807 in this case) to prove that the UE 801 has access rights, and the network/resource 807 grants access rights.
In step S818, the network/resource 807 returns an access acknowledgement to the UE 801 that may then access the LTS hosting network 807.
In one variation, the TS 805 replies to the UE 801 with a list of available LTS-hosted networks or other resources.
Both AV and AT are temporary and available for single use, set time use, etc. This may eliminate the need for explicit revocation.
The credential server 803 may be an extension of the existing authentication functionality in 5 GS.
Automatic access to hosted networks
As described above, for an LTS managed network, a UE may obtain a network identifier or CAG identifier of the managed network, a temporary UE identifier of the managed network, temporary credentials of the managed network, an area where LTS services are available, and a period of time where LTS services are available.
To discover an LTS-hosted network or CAG cell, the UE may begin a periodic network scanning procedure within a period and in an area where LTS services are available. The scanning process may be triggered by a timer or when the user agrees to use the service. If a hosted network or CAG cell can be found that matches the network identifier or CAG identifier, the UE may present the discovered network or CAG cell to the user. If the user instructs the UE to hand over to the hosted network or CAG cell, the UE may use the stored temporary credentials to begin registering with the hosted network or reselecting the CAG cell. The UE may de-register from its current serving PLMN or inform the serving PLMN that it will temporarily leave for LTS service.
In one embodiment, the service provider and hosting network may track the location of the user through the PLMN. When the hosting network detects that the user (i.e., UE 901) is within its LTS service area, it may send a notification to the user through PLMN signaling. The notification may trigger the UE to search for the hosted network and switch to the hosted network if the hosted network is found. For example, the hosting network may subscribe to event notifications about UE location reports or UE presence in the "region of interest" through the NEF in the PLMN. When a UE is detected within its service area, the hosting network may invoke an application trigger service of the NEF to deliver a notification (e.g., SMS notification) to the UE. After receiving the notification, the UE may begin searching for and switching to the hosted network.
Fig. 9 illustrates automatic network access triggering using PLMN location and application triggering services in more detail according to one embodiment. In step S902, the AF 909 may send a request for a report on the location of the UE 901 to the NEF 907 (e.g., a nnef_eventExposure_subscore request, including an indication that the request is for a location report and GPSI of the UE 901). In step S904, the NEF 907 forwards the request to the UDM 905 (e.g., the nudm_eventExponsure_substrice request, including an indication that the request is a location report and identifier for the UE 901). In step S906, the UDM 905 forwards the request to the AMF 903 or GMLC (e.g., namf_location_service message, including an indication that the request is a Location report and identifier for the UE 901). In step S908, the AMF 903 (or GMLC) returns a location report with location data of the UE 901 (e.g., a namf_eventExposure_notify message with the location data) to the NEF 907. In step S910, the NEF 907 forwards the location report with the location data of the UE 901 to the AF 909 (e.g., nne_eventExposure_notify message with location data). Based on the location data of the UE 901, the AF may determine whether the UE is in the LTS service area in step S912. In step S914, the AF 909 sends a Delivery request (e.g., nnef_trigger_delivery request) to the NEF 907, and then in step S916, a Trigger Delivery procedure is sent, for example, as described in 3gpp TS 23.501, "System architecture of 5G System (System Architecture for the G System)", V16.6.0, 2020-09, clause 4.13.2.2. Then, in step S918, the UE 901 may register with the managed network.
Remote preset
If the UE uses a PLMN or SNPN as the loading network, the UE may indicate its LTS service capability when the UE registers with the PLMN, e.g., in a registration request message or during a service request. For example, the loading network (PLMN or SNPN) may return the configuration of the DNN/S-NSSAI combination for the remote preset LTS network in a registration accept or service accept message or a UE configuration update message. The DNN/S-NSSAI may be a generic configuration for all LTS network related remote presets.
When the UE initiates PDU session establishment in the load network for the remote preset target LTS network, it may use the previously received DNN/S-NSSAI combination for PDU session request. It may also include an explicit indication that a PDU session is requested for the remote preset LTS network. The UE may also include additional target LTS service or network information in the PDU session establishment request, such as a target LTS service identifier or name, a target LTS managed network identifier or name, and the like. The UE may have acquired this additional service information through LTS service advertising (e.g., from a web portal or a short message). Using the target LTS service information provided by the UE, the loading network (PLMN or SNPN) may identify a corresponding remote preset configuration (e.g., PVS address) and return it to the UE in a PDU session establishment accept message or UE configuration update message, etc. The UE may then access a pre-set server of the target LTS network using the established PDU session and the received configuration (e.g., PVS address) to retrieve LTS network credentials and other information for selecting and accessing the target LTS network.
Alternatively, when a LTS-capable UE indicates its LTS service capability to the loading network, e.g., in a registration request message or during a service request, the loading network (PLMN or SNPN) may return a list supported by the loading network for preset LTS service information (e.g., the loading network has a service agreement with these LTS service providers). The list may include supported LTS service identifiers/names, corresponding LTS managed network identifiers and names, DNN/S-NSSAI combinations for remotely provisioning the LTS networks, remote provisioning configurations (e.g., PVS addresses) for the LTS networks, and so on. The loading network may provide a list of LTS service information during a registration procedure (e.g., in a registration accept message), a service request procedure (e.g., in a service accept message), or a UE configuration update procedure.
After receiving the list of supported LTS service information, the UE may select a target LTS service and establish a PDU session for remote preset using a corresponding configuration (e.g., DNN/S-NSSAI combination corresponding to the target LTS service) and access a preset server using the remote preset configuration (e.g., PVS address) and retrieve LTS network credentials and other information for selecting and accessing the target LTS network.
Alternatively, when a LTS-capable UE indicates its LTS service capability to the loading network, e.g., in a registration request message or during a service request, the UE may additionally provide a target LTS service (such as a target LTS service identifier or name, a target LTS managed network identifier or name, etc.) to the loading network. The loading network (PLMN or SNPN) may return target LTS service information, which may include DNN/S-NSSAI combinations for remotely presetting target LTS services, remote preset configurations (e.g., PVS addresses) for target LTS services, and so on. The loading network may provide this information during a registration procedure (e.g., in a registration accept message), a service request procedure (e.g., in a service accept message), or a UE configuration update procedure.
After receiving the list of target LTS service information, the UE may establish a PDU session for remote preset using a corresponding configuration (e.g., DNN/S-nsai combination corresponding to the target LTS service), and may access a preset server using the remote preset configuration (e.g., PVS address) and retrieve LTS network credentials and other information for selecting and accessing the target LTS network.
In another embodiment, if the loading network is an SNPN, the SNPN may broadcast LTS service information that it supports (for presetting), and the UE may use the broadcasted information to select the loading network. For example, if the UE's target LTS service/network is in a broadcast list of LTS service information for the SNPN, the UE may select the SNPN as the loading network. The UE may then indicate its target LTS service/network to the loading network, e.g., in a registration request, service request, or PDU session establishment request, and the network may return the corresponding configuration (e.g., DNN/S-nsai combination and PVS address, etc.) to the UE.
Fig. 10 is a signal flow diagram illustrating an exemplary process for remotely provisioning a UE in accordance with the principles described above. In step S1002, when the UE 1001 registers with the loading network 1003 (e.g., PLMN or SNPN), it includes its LTS service capability in the loading registration request. In response, the network 1003 returns a registration accept message including a configuration of the DNN/S-nsai combination for remotely provisioning the LTE network in step S1004.
Then, when it is required to join the LTS network, the UE 1001 initiates PDU session establishment in the loading network 1003 for remote preset of the target LTS network in step S1006. In the PDU session establishment request message, the UE may use the previously received DNN/S-NSSAI combination. It may also include in the PDU session setup request message an explicit indication that the PDU session is requested for a remote preset LTS network and/or additional target LTS service or network information (such as target LTS service identifier or name, target LTS managed network identifier or name, etc.), which may have been obtained by the LTS service advertisement. Using the target LTS service information provided by the UE, the network 1003 identifies the corresponding remote preset configuration (e.g., PVS address) and returns it to the UE in a PDU session establishment accept message (or, alternatively, a UE configuration update message) in step S1008. As shown in step S1010, the UE 1001 may now access a preset server of the target LTS network using the established PDU session and the received configuration (e.g., PVS address) to retrieve LTS network credentials and other information for selecting and accessing the target LTS network.
Conclusion(s)
Although features and elements are provided above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Functionally equivalent methods and apparatus, other than those enumerated herein, which are within the scope of the present disclosure, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.
For simplicity, the foregoing embodiments are discussed with respect to the terminology and structure of infrared-capable devices (i.e., infrared emitters and receivers). However, the embodiments discussed are not limited to these systems, but may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as acoustic waves).
It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and/or multiple images that are displayed on a temporal basis. As another example, as referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and/or the term "head mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and/or receive unit (WTRU); (ii) Any of a number of embodiments of the WTRU; (iii) Devices with wireless capabilities and/or with wired capabilities (e.g., tethered) are configured with some or all of the structure and functionality of a WTRU, in particular; (iii) Wireless capability and/or wireline capability devices configured with less than the full structure and functionality of the WTRU; or (iv) etc. Details of an exemplary WTRU that may represent any of the WTRUs described herein are provided herein with respect to fig. 1A-1D. As another example, various disclosed embodiments herein above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted real-world experience.
Additionally, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and Digital Versatile Disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.
Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. In view of the various embodiments that may be employed, it should be understood that the illustrated embodiments are examples only and should not be taken as limiting the scope of the following claims. For example, embodiments provided herein include a handheld device that may include or be used with any suitable voltage source (such as a battery or the like) that provides any suitable voltage.
Furthermore, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.
Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit. It should be understood that embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.
The data bits may also be maintained on computer readable media including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by the CPU. The computer readable media may comprise cooperating or interconnected computer readable media that reside exclusively on the processing system or are distributed among a plurality of interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that embodiments are not limited to the above-described memories, and that other platforms and memories may support the provided methods.
In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer readable instructions stored on a computer readable medium. The computer readable instructions may be executed by a processor of the mobile unit, the network element, and/or any other computing device.
There is little distinction between hardware implementations and software implementations of aspects of the system. The use of hardware or software is often (but not always, as in some contexts the choice between hardware and software may become important) a design choice representing a tradeoff between cost and efficiency. There may be various media (e.g., hardware, software, and/or firmware) that may implement the processes and/or systems and/or other techniques described herein, and the preferred media may vary with the context in which the processes and/or systems and/or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a medium of mainly hardware and/or firmware. If flexibility is paramount, the implementer may opt for a particular implementation of mainly software. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.
The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Where such block diagrams, flowcharts, and/or examples include one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, portions of the subject matter described herein may be implemented by Application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), digital Signal Processors (DSPs), and/or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media such as digital and/or analog communications media (e.g., fiber optic cable, waveguide, wired communications link, wireless communications link, etc.).
Those skilled in the art will recognize that it is common in the art to describe devices and/or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing; a video display device; memories such as volatile memories and nonvolatile memories; a processor, such as a microprocessor and a digital signal processor; computing entities such as operating systems, drivers, graphical user interfaces, and applications; one or more interactive devices, such as a touch pad or screen; and/or a control system comprising a feedback loop and a control motor (e.g. feedback for sensing position and/or speed, a control motor for moving and/or adjusting components and/or amounts). Typical data processing systems may be implemented using any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.
The subject matter described herein sometimes illustrates different components included within or connected with different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, physically mateable and/or physically interactable components and/or wirelessly interactable components and/or logically interactable components.
With respect to substantially any plural and/or singular terms used herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly listed herein.
It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will be further understood by those with skill in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the following appended claims and/or descriptions herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation object by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation object to embodiments containing only one such recitation object. Even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). In addition, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). It should also be understood by those within the art that virtually any separate word and/or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B". In addition, as used herein, the term "…" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "multiple".
Additionally, where features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will recognize thereby that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.
As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as sufficiently descriptive and so that the same range can be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, and the like. As will also be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc., include the recited numbers and refer to ranges that may be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the scope includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, or the like.
Furthermore, the claims should not be read as limited to the order or elements provided, unless stated to that effect. In addition, use of the term "means for …" in any claim is intended to invoke 35U.S. C. ≡112,6 or device plus function claims format, and any claims without the term "device for …" are not intended to be so.
Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), and/or a state machine.
The WTRU may be used in combination with a module, and may be implemented in hardware and/or software including: software Defined Radio (SDR) and other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, and the like,A module, a Frequency Modulation (FM) radio unit, a Near Field Communication (NFC) module, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module. / >
While various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor/general purpose computer (not shown). In some embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.
In addition, while the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.
Reference to
The following references may have been mentioned above, the entire contents of which are incorporated herein by reference.
[1]3GPP S1-203276, "Study on 5G networks providing localized service Access rights (Studiy on 5G Networks Providing Access to Localized Services)",
[2]3gpp TS 23.501, "System architecture of 5G System (System Architecture for the 5G System)", V17.1.1, 2021-06
[3]3gpp TS 23.502, "procedure for 5G System (Procedures for the G System)", V17.1.0, 2021-06
[4]3gpp TS 23.122, "Non-Access-Stratum (NAS) function (Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode) related to Mobile Station (MS)", V16.7.0, 2020-09
[5]3GPP TS 23.273, "5G System (5 GS) location services (LCS) (5G System (5 GS) Location Services (LCS))", V16.4.0, 2020-07
[6]3GPP TS 23.246, "multimedia broadcast/multicast service (MBMS); architecture and functional description (Multimedia Broadcast/Multicast Service (MBMS); architectureand functional description), "V16.1.0)

Claims (28)

1. A method implemented in a wireless transmit/receive unit (WTRU) of provisioning the WTRU for communication in a temporary local network, the method comprising:
transmitting information to a loading network regarding the WTRU's ability to communicate with the temporary local network;
receiving configuration information from the loading network to preset the temporary local network;
receiving a message from the loading network using the received configuration information, the message identifying a preset configuration for use by the WTRU with the temporary local network; and
and sending a message to the temporary local network by using the preset configuration.
2. The method of claim 1, the method further comprising:
at least one identifier of a service is sent to the loading network.
3. The method of claim 2, wherein the preset configuration comprises a preset server address of the service.
4. The method of claim 1, wherein the temporary local network is a Localized Temporary Service (LTS) network.
5. The method of claim 1, wherein transmitting information about the capabilities to the loading network comprises: a registration request is sent that includes the information about the capability.
6. The method of claim 1, wherein the configuration information is for a data network and a network slice.
7. The method of claim 6, wherein the configuration information is for a data network name/single network slice selection assistance information (DNN/S-nsai) combination to preset the temporary local network and is received in at least one of a registration accept message and a service accept message.
8. The method of claim 1, the method further comprising:
establishing a session in the temporary local network; and retrieving credentials used in the temporary local network from a provisioning server of the temporary local network, the provisioning server being accessed using the session and the provisioning configuration.
9. The method of claim 1, wherein receiving a message identifying a preset configuration comprises: establishing a session using Protocol Data Unit (PDU) session establishment; and wherein the message identifying the preset configuration is at least one of a PDU session establishment accept message and a UE configuration update message.
10. A wireless transmit/receive unit (WTRU), the WTRU comprising:
a memory configured to store program code instructions; and
at least one processor configured to execute the program code instructions to:
transmitting information to the loading network regarding the WTRU's ability to communicate with a temporary local network;
receiving configuration information from the loading network to preset the temporary local network;
receiving a message from the loading network using the received configuration information, the message identifying a preset configuration for use by the WTRU with the temporary local network; and
and sending a message to the temporary local network by using the preset configuration.
11. The WTRU of claim 10, wherein the at least one processor is further configured to: the program code instructions are executed to provide at least one identifier of a service to the loading network.
12. The WTRU of claim 11 wherein the preset configuration comprises a preset server address of the service.
13. The WTRU of claim 10 wherein the temporary local network is a Localized Temporary Service (LTS) network.
14. The WTRU of claim 10, wherein the WTRU transmitting information about the capabilities to the loading network comprises: a registration request is sent that includes the information about the capability.
15. The WTRU of claim 10 wherein the configuration information is for a data network and a network slice.
16. The WTRU of claim 15 wherein the configuration information is for a data network name/single network slice selection assistance information (DNN/S-nsai) combination to preset the temporary local network and is received in at least one of a registration accept message and a service accept message.
17. The WTRU of claim 10, wherein the at least one processor is further configured to: establishing a session in the temporary local network; and retrieving credentials used in the temporary local network from a provisioning server of the temporary local network, the provisioning server being accessed using the session and the provisioning configuration.
18. The WTRU of claim 10, wherein receiving a message identifying a preset configuration comprises: establishing a session using Protocol Data Unit (PDU) session establishment; and wherein the message identifying the preset configuration is at least one of a PDU session establishment accept message and a UE configuration update message.
19. A method, the method comprising:
receiving information corresponding to a subscription request from a wireless transmit/receive unit (WTRU) in a first network; and
A temporary credential is sent to the WTRU for use by the WTRU.
20. The method of claim 19, wherein the first network is a public land mobile network.
21. The method of claim 19, the method further comprising:
monitoring the subscription request through a network open framework of the first network.
22. The method of claim 19, the method further comprising:
the temporary credentials of the WTRU and a pre-set server/database are created in a second network.
23. The method of claim 19 wherein the temporary credentials are sent to the WTRU over a public land mobile network open framework.
24. An apparatus, the apparatus comprising:
a memory configured to store program code instructions; and
at least one processor configured to execute the program code instructions to:
receiving information corresponding to a subscription request from a wireless transmit/receive unit (WTRU) in a first network; and
a temporary credential is sent to the WTRU for use by the WTRU.
25. The apparatus of claim 24, wherein the first network is a public land mobile network.
26. The apparatus of claim 24, wherein the at least one processor is further configured to: monitoring the subscription request through a network open framework of the first network.
27. The apparatus of claim 24, wherein the at least one processor is further configured to: the temporary credentials of the WTRU and a pre-set server/database are created in a second network.
28. The apparatus of claim 24, wherein the at least one processor is further configured to: the temporary credentials are sent to the WTRU over a public land mobile network open framework.
CN202180080788.XA 2020-11-02 2021-11-02 Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials Pending CN116530116A (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63/108,539 2020-11-02
US202163230383P 2021-08-06 2021-08-06
US63/230,383 2021-08-06
PCT/US2021/057734 WO2022094469A1 (en) 2020-11-02 2021-11-02 Method and apparatus for provisioning of localized temporary services (lts) hosting network credentials

Publications (1)

Publication Number Publication Date
CN116530116A true CN116530116A (en) 2023-08-01

Family

ID=87390806

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180080788.XA Pending CN116530116A (en) 2020-11-02 2021-11-02 Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials

Country Status (1)

Country Link
CN (1) CN116530116A (en)

Similar Documents

Publication Publication Date Title
CN111034273B (en) Terminal requesting network slicing capability from non-3 GPP access networks
CN113891432B (en) WTRU and method for wireless communication implemented in WTRU
KR102472434B1 (en) Relocate custom plane
US20230413049A1 (en) Method and apparatus for provisioning of localized temporary services (lts) hosting network credentials
CN114600483A (en) Device-to-device discovery by a relay device
CN117957863A (en) WTRU-to-network relay associated with MINT
CN115136722A (en) Methods, architectures, devices and systems for improved service continuity for out-of-range proximity wireless transmit/receive devices
US20240129968A1 (en) Methods, architectures, apparatuses and systems for supporting multiple application ids using layer-3 relay
CN112640370B (en) Method and apparatus for layer 2 forwarding of multicast packets
JP2022550807A (en) Method and Apparatus for PROSE Peer Discovery
CN115486201A (en) Method and apparatus for end-to-end quality of service for communications between wireless transmit-receive units
CN115088284A (en) System and method relating to enhanced broadcast services in a multi-access point system
CN114788323A (en) Discovery based on 5G ProSe services
CN116530116A (en) Method and apparatus for provisioning Localized Temporary Service (LTS) escrow network credentials
CN114642012B (en) Method and apparatus for PROSE peer discovery
US20230308840A1 (en) Multicast-broadcast services support for network relay
CN117397308A (en) Method and apparatus for steering a wireless transmit/receive unit between a plurality of wireless networks
CN116018825A (en) Method and apparatus for discovering and selecting local NEF
CN117529937A (en) Remote WTRU multicast and broadcast service transmission via relay WTRUs
CN117397231A (en) Method and device for terminal function distribution
CN117321971A (en) Method, architecture, apparatus and system for unified edge configuration server provisioning
CN117280751A (en) Service continuity during application context relocation procedure
CN116897592A (en) Multiple application identification using layer 3 relay
WO2023081415A1 (en) Service provisioning and configuration for accessing pals hosting network
CN116941232A (en) Method, apparatus and system for integrating constrained multi-access edge computing hosts in a multi-access edge computing system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination