Core network assisted service discovery

Abstract

The invention relates to core network assisted service discovery. Methods and apparatus for integrating NF discovery and application layer service capability discovery in a communication network such as a 3GPP NR (e.g., 5G) network are disclosed.

Description

[0001] This application is a divisional application of the PCT application entering the Chinese national phase, with an international filing date of July 9, 2019, national application number 201980046050.4, and invention name “Core Network Assisted Service Discovery”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of and priority to U.S. Provisional Patent No. 62 / 695,280, filed on July 9, 2018, the entire contents of which are incorporated herein by reference. Background Art

[0004] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology, known as New Radio (NR), also referred to as "5G."

[0005] In the current version of the 3GPP NR specification, the core network (CN) performs network function (NF) discovery in order to find one or more network functions to provide the service requested by the user equipment (UE). In a separate process, once the UE obtains network connectivity, the Internet of Things (IoT) applications hosted on the UE will typically perform application layer service discovery in order to find IoT servers and applications (e.g., hosted on other UEs) that provide the desired service. Currently, NF discovery and application layer service discovery are performed separately in 5G networks. Summary of the invention

[0006] Disclosed herein are methods and apparatus for integrating NF discovery and application layer service discovery in a communication network such as a 3GPP NR (e.g., 5G) network.

[0007] In one aspect, a method for UEs and application servers to advertise their service capabilities within a core network to make the service capabilities discoverable is disclosed.

[0008] In another aspect, a method for a UE to initiate service discovery in a core network as part of a registration process is disclosed. Alternatively, a method for a UE to initiate service discovery as part of a PDU session establishment procedure is disclosed.

[0009] In another aspect, a method for a UE to subscribe to a certain service capability in a core network is disclosed.

[0010] In yet another aspect, a method for server-initiated service discovery in a core network is disclosed.

[0011] New network services that may be provided by the network repository function to enable service discovery in the core network are also disclosed.

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

[0013] The present invention may be understood in more detail from the following description, which is given by way of example with reference to the accompanying drawings, in which:

[0014] Figure 1 An example communication system is illustrated;

[0015] Figure 2 is a block diagram of an example apparatus or device, such as, for example, a wireless transmit / receive unit (WTRU), configured for wireless communications;

[0016] Figure 3 is a system diagram of a first example radio access network (RAN) and core network;

[0017] Figure 4 is a system diagram of a second example RAN and core network;

[0018] Figure 5 is a system diagram of a third example radio access network RAN ​​and a core network;

[0019] Figure 6 is a system diagram of a fourth example radio access network RAN ​​and a core network;

[0020] Figure 7 is a block diagram of an example computing system in which nodes of a communication system may be implemented;

[0021] Figure 8 is a block diagram of a non-roaming network architecture having a service-based interface within a control plane of a core network;

[0022] Fig. 9 It is presented Figure 1 Another view of a network and a block diagram illustrating reference points through which various network functions interact;

[0023] Fig.10 The concept of network slicing is illustrated;

[0024] Fig.11 is a diagram illustrating a use case involving service discovery over a mobile core network;

[0025] Fig.12 is a diagram of a protocol stack illustrating use of a NAS connection to transfer service capability information to / from a core network and to initiate a service discovery process at an NRF;

[0026] Fig.13 is a call flow illustrating a method by which a UE may advertise service capability information to a core network;

[0027] Fig.14 is a call flow illustrating a method by which an SCS / AS may advertise service capability information to a core network;

[0028] Fig.15 is a call flow illustrating a registration procedure modified to allow the UE to initiate service discovery during registration;

[0029] Fig.16 is a call flow illustrating a method by which the AMF may insert service capability information during a registration procedure requiring AMF reallocation and may trigger service discovery using the NF Discovery Request message;

[0030] Fig.17 is a call flow illustrating a UE initiated PDU session establishment procedure, the PDU session establishment procedure being modified to allow the UE to initiate service discovery during PDU session establishment;

[0031] Fig.18 is a call flow illustrating an SMF selection process modified to allow service discovery during SMF selection;

[0032] Fig.19 is a call flow illustrating a method by which a UE may subscribe to receive notifications about certain device / SCS / AS service capabilities;

[0033] Fig. 20 is a call flow illustrating a method for SCS / AS initiated service discovery in a core network;

[0034] Fig.21 is a diagram illustrating an example user interface for configuring service discovery in a communication network. DETAILED DESCRIPTION

[0035] The following is a list of acronyms that may appear in the following descriptions. Unless otherwise noted, the acronyms used in this article refer to the corresponding terms listed below:

[0036] AF application function

[0037] AMF access and mobility management function

[0038] AS Application Server

[0039] AUSF authentication server function

[0040] CM connection management

[0041] CN Core Network

[0042] CP Control Plane

[0043] DL Downlink

[0044] DNN data network name

[0045] EPC Evolved Packet Core

[0046] EPS Evolved Packet System

[0047] FQDN Fully Qualified Domain Name

[0048] LTE Long Term Evolution

[0049] MME mobility management entity

[0050] NAS non-access layer

[0051] NRF NF Repository Function

[0052] NEF network exposure function

[0053] NF Network Function

[0054] NIDD Non-IP Data Delivery

[0055] NSSF network slice selection function

[0056] NWDAF network data analysis function

[0057] PCF policy control function

[0058] QoS Quality of Service

[0059] RAN Radio Access Network

[0060] SCS Service Capability Server

[0061] SCEF service capability exposure function

[0062] SMF session management function

[0063] SMSF Short Message Service (SMS) Function

[0064] SPR Subscription Profile Repository

[0065] UDM / UDR unified data management / unified data repository

[0066] UDSF unstructured data storage function

[0067] UE User Equipment

[0068] UL Uplink

[0069] UPF user plane function

[0070] The following terms may have the following meanings:

[0071] A "network function (NF)" may be a processing function in a network with defined functional behavior and defined interfaces. A NF may be implemented either as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., on a cloud infrastructure).

[0072] A "network service" may be a service provided by a network function to another network function in a service-based architecture. A service may be advertised to the NRF. For example, the AMF provides the Namf_EventExposure service, which enables the AMF to send notifications to NFs that subscribe to certain mobility management related events.

[0073] "Device / SCS / AS service" may refer to a higher layer (eg, service layer or application layer) service, capability, or function provided by a device, service capability server, or application server. For example, an application server may provide device management services.

[0074] A "PDU Session" may be an association between a UE and a data network that provides PDU connectivity services. There are at least two types of PDU Sessions: (1) IP type - that is, the data network is IP type; and (2) non-IP type - the data network is non-IP.

[0075] A "UE capability profile" may describe what a UE is capable of. This profile is usually static. For example, whether the UE has relay capability, the category of the UE (e.g., maximum data rate), screen size, voice capability, IMS capability, GPS capability, etc. This information may be maintained in the UE subscription configuration and / or SIM.

[0076] "Session Management in 3GPP CN" refers to session management in 3GPP CN. In 3GPP CN, ​​session management will manage the end-to-end PDN connection (IP or non-IP type) between the UE and the packet data network for data transmission through the core network with policies (such as QoS) and charging control implemented.

[0077] “Service capabilities” refers to any type of service supported by the service layer of a communication network. Examples include device management, group management, service discovery, subscription / notification services, smart transportation services, environmental monitoring, etc.

[0078] "Core Network" refers to the central or core part of a telecommunications network that provides a multitude of communication services to customers interconnected by radio access networks. A core network typically includes several entities that perform core network functions. As used herein, the term "core network entity" refers to any entity that performs a function of a core network, such as, for example, AMF, UDR / UDSF, UDM / UDR, NRF, NEF, PCF, NF, SMF, AUSF, NSSF, etc. as described herein. It should be understood that such core network entities may be stored in a network such as a Figure 2 or Figure 7 Logical entities implemented in the form of software (ie, computer executable instructions) in the memory of the computer system or device configured for wireless and / or network communications shown in and executed on its processor.

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

[0080] 3GPP has identified a variety of use cases that New Radio (NR) is expected to support, resulting in various user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, ubiquitous 50+Mbps, ultra-low-cost broadband access, in-vehicle mobile broadband), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and intercommunication, energy saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive eCall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, among others. All of these use cases and others are contemplated herein.

[0081] Figure 1An embodiment of an example communication system 100 is illustrated in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e Figure 1-6 , but it should be understood that for various use cases contemplated for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronics product, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane, etc.).

[0082] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112). The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmission and reception points) 119a, 119b to facilitate access to one or more communication networks (such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112). The RRHs 118a, 118b may be any type of device configured to interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTS), Node-Bs (Node Bs), eNode Bs, home Node Bs, home eNode Bs, site controllers, access points (APs), wireless routers, and the like. While 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.

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

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

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

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

[0087] More specifically, as described above, the communication system 100 may be a multiple-access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d 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 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0088] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advance (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology.

[0089] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0090] Figure 1 The base station 114c in the example may be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, etc. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 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 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Figure 1 As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

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

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

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

[0094] 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, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1 The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

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

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

[0097] The transmission / reception element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the transmission / reception element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmission / reception element 122 may be a transmitter / detector configured to, for example, transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmission / reception element 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmission / reception element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0098] In addition, although the transmit / receive element 122 is Figure 2Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an 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 115 / 116 / 117.

[0099] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

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

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

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

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

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

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

[0106] like Figure 3 As shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c connected thereto. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, switching control, macro diversity, security functions, data encryption, etc.

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

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

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

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

[0111] Figure 4 1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0112] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the 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 for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

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

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

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

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

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

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

[0119] Figure 5 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0120] like Figure 5 As shown, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0121] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0122] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating handovers and data transfers of WTRUs between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0123] like Figure 5 As shown, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0124] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0125] Although not in Figure 5 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0126] This article describes and Figure 1-6 The core network entities shown in are identified by the names given to those entities in certain existing 3GPP specifications, but it should be recognized that in the future, those entities and functions may be identified by other names, and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Figure 1-6 The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or in the future.

[0127] Figure 6The 5G core network 170 shown in the figure may include an access and mobility management function (AMF) 172, a session management function (SMF) 174, a user plane function (UPF) 176, a user data management function (UDM) 178, an authentication server function (AUSF) 180, a network exposure function (NEF), a policy control function (PCF) 184, a non-3GPP interworking function (N3IWF) 192, and an application function (AF) 188. Although each of the aforementioned elements is depicted as part of the 5G core network 170, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be appreciated that the 5G core network may not consist of all of these elements, may include additional elements, and may include multiple instances of each of these elements. Figure 6 The network functions are shown connected directly to each other, however, it should be appreciated that they may communicate via a routing agent such as a Diameter routing agent or a message bus.

[0128] The AMF 172 may be connected to each of the RAN 103 / 104 / 105 / 103b / 104b / 105b via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, 102c.

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

[0130] The SMF 174 may also be connected to the UPF 176, which may provide the WTRUs 102a, 102b, 102c with access to a data network (DN) 190, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The SMF 174 may manage and configure traffic steering rules in the UPF 176 via an N4 interface. The UPF 176 may be responsible for interconnecting packet data unit (PDU) sessions with data networks, packet routing and forwarding, policy rule enforcement, quality of service handling of user plane traffic, and downlink packet buffering.

[0131] The AMF 172 may also be connected to the N3IWF 192 via an N2 interface. The N3IWF facilitates connectivity between the WTRUs 102a, 102b, 102c and the 5G core network 170 via a radio interface technology that is not defined by 3GPP.

[0132] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. PCF 184 may provide policy rules to control plane nodes such as AMF 172 and SMF 174, allowing the control plane nodes to enforce the rules.

[0133] UDM 178 acts as a repository for authentication credentials and subscription information. UDM can be connected to other functions such as AMF 172, SMF 174 and AUSF 180.

[0134] AUSF 180 performs operations related to authentication and is connected to UDM 178 via an N13 interface and to AMF 172 via an N12 interface.

[0135] NEF exposes capabilities and services in the 5G core network 170. NEF can be connected to AF 188 via an interface, and can be connected to other control plane and user plane functions (180, 178, 172, 172, 184, 176, and N3WF) to expose the functions and services of the 5G core network 170.

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

[0137] Figure 7is a block diagram of an exemplary computing system 90 in which one or more devices of the communication network illustrated or described herein, such as certain nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110 or other networks 112, may be implemented.

[0138] The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever or in whatever manner such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor different from the main processor 91 that may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

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

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

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

[0143] Additionally, computing system 90 may include communications circuitry, such as a network adapter 97, which may be used to connect computing system 90 to an external communications network, such as a Figure 1-6 The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112) of the present invention can be used to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit system can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

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

[0145] Figure 8 is a block diagram of a non-roaming network architecture for a 5G network with a service-based interface within a control plane of the network. Fig. 9 It is presented Figure 1 Another view of the 5G network and a block diagram illustrating the reference points through which the various network functions interact. Note that the mobility management and session management functions are separated. A single N1 NAS connection is used for registration management and connection management (RM / CM), as well as SM-related messages and procedures for the UE. The single N1 termination point is located in the AMF. The AMF forwards the SM-related NAS information to the SMF. The AMF handles the registration management and connection management part of the NAS signaling exchanged with the UE. The SMF handles the session management part of the NAS signaling exchanged with the UE.

[0146] like Figure 8 As shown, the NF Repository Function (NRF) is defined in the 5G service-based framework as a logical function used to support the following functions:

[0147] Support service discovery function. Receive NF discovery request from NF instance and provide the information of discovered NF instance to NF instance;

[0148] Maintain NF profiles of available NF instances and their supported services information.

[0149] The NF profile of a NF instance maintained in NRF may include the following information:

[0150] NF instance ID

[0151] NF type

[0152] PLMNID

[0153] Identifier(s) associated with the network slice, e.g. S-NSSAI,

[0154] NSI ID

[0155] NF’s FQDN or IP address

[0156] NF capability information

[0157] NF-specific service authorization information

[0158] The name of the supported service

[0159] Endpoint information for each supported service instance(s)

[0160] Identification of the stored data / information.

[0161] Table 1 defines the NRF services and service operations. Specifically, the NRF will perform registration / deregistration and updates on the NF and help other entities (e.g., NF and SCS / AS) discover the desired NF.

[0162] Table 1: NF services provided by NRF

[0163]

[0164] Network slicing is a mechanism that mobile network operators can use to support multiple "virtual" networks behind the air interface across the fixed portion of the mobile operator's network (both backhaul and core network). This involves "slicing" the network into multiple virtual networks to support different radio access networks (RANs) or different service types running across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios that require different requirements (e.g., in terms of functionality, performance, and isolation). Fig.10 The conceptual architecture of network slicing is shown. A network slice instance consists of a set of network functions and the resources to run these network functions. Different shading is used to indicate different network slice instances or subnet slice instances. A subnet slice instance includes a set of network functions and the resources to run these network functions, but it is not a complete logical network itself. A subnet slice instance can be shared by multiple network slice instances.

[0165] 3GPP is considering incorporating network slicing technology into 5G networks. This technology is well suited for 5G networks because 5G use cases (e.g., massive Internet of Things (IoT), critical communications, and enhanced mobile broadband) have very diverse and sometimes extreme requirements. The current pre-5G architecture uses a relatively single network and transport framework to accommodate a variety of services, such as mobile traffic from smartphones, over-the-top (OTT) content, feature phones, data cards, and embedded machine-to-machine (M2M) devices. It is expected that the current architecture is not flexible and scalable enough to efficiently support these services when each of the services in the broader business needs has its own specific set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be made more efficient. In any case, it is expected that several use cases will be active at the same time in the same operator network, so 5G networks need to be highly flexible and scalable. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with different requirements (e.g., in terms of functionality, performance, and isolation).

[0166] Fig.11 is a diagram illustrating a use case involving device / SCS / AS service discovery and network function (i.e., network service) discovery over a 3GPP core network. In this example, Application Server 1 (i.e., SCS1) provides smart transportation services by monitoring street traffic in real time and collecting traffic statistics. Application Server 2 (i.e., SCS2) manages a set of sensors that monitor and measure environmental data such as air quality, humidity, and temperature. Both servers provide their own service discovery functionality and can be accessed over the mobile core network.

[0167] As further shown, a first device, which may be referred to as device 1 (e.g., UE1), may be looking for a device / SCS / AS service that can provide traffic monitoring and statistics. Prior to the methods and systems disclosed herein, UE1 must connect to SCS1 and SCS2 through a mobile core network and perform device / SCS / AS service discovery at each application server, respectively. In this way, device 1 can discover that SCS1 can provide such information, and then device 1 can maintain a connection with SCS1.

[0168] As further shown, two application servers may be looking for devices that can provide device / SCS / AS service data that matches their interests. In other words, SCS1 tries to find some devices that provide traffic monitoring data, and SCS2 tries to find devices that provide real-time environmental measurements (such as air quality and temperature). The application server can perform the service discovery process by communicating with each individual device (i.e., UE2-UE7) via the core network. However, this is inefficient because it requires a lot of communication between the application server and each individual device.

[0169] exist Fig.11 As can be seen in the example, UE1 needs to connect to each available application server to perform device / SCS / AS service discovery so that it can determine whether the application server can provide the device / SCS / AS service it is looking for. This is especially true in the IoT field, because there may be various IoT servers deployed by different third-party application service providers, that is, the IoT service provision is very decentralized. There is usually no centralized server to maintain all service contexts for different verticals (e.g., smart transportation, industry, and healthcare). In this sense, it is not efficient to perform a device / SCS / AS service discovery process at each application server through the mobile core network.

[0170] In addition, each application server only knows the service context under its management. Therefore, the application server does not know the service context information of other application servers, which makes the service discovery process less efficient. For example, both smart transportation and environmental monitoring services may have some monitoring cameras on the street, but without the cooperation between the two application servers, each AS cannot know each other's services. Performing device / SCS / AS service discovery separately at each SCS / AS may not lead to the best choice for providing services, because each SCS / AS only has the knowledge of its own domain.

[0171] Application servers (e.g., SCS1 and SCS2) may be able to query individual devices to discover devices that can be used to provide the desired service (e.g., traffic monitoring). In addition, the application server may even know some device context information that may be relevant to the desired service (e.g., the location of those available devices). However, the application server does not know the network status of these devices. For example, assume that UE2 is an environmental sensor and is in sleep mode and cannot be accessed through the mobile core network until 12 hours later. UE3 may be able to efficiently transmit small data through the control plane of the core network. UE4 can be accessed not only via 3GPP access, but also via non-3GPP access (such as WiFi). Service discovery cannot reveal this type of transmission network capability information. This means that performing device / SCS / AS service discovery without considering the underlying network status may result in inefficient data communication when enabling services or services are in operation.

[0172] Some service discovery requirements have been specified for 5G systems but have not yet been addressed in the system. In particular, it has been specified that the 5G system should efficiently support a service discovery mechanism where a UE can discover (i) the state of other UEs (e.g., sound on / off); (ii) the capabilities of other UEs (e.g., the UE is a relay UE), and / or (iii) the services provided by other UEs (e.g., the UE is a color printer) based on access rights.

[0173] Currently, the 5G core network performs network function discovery to find the NF that serves the UE. For example, AMF can interact with NRF to discover SMF that meets specific standards. SMF can interact with NRF to discover UPF that meets specific standards.

[0174] Once a UE obtains network connectivity, an IoT application hosted by the UE will typically perform service discovery in order to find IoT servers (ie, SCS / AS) and IoT applications (eg, hosted on other UEs) that provide its desired services.

[0175] This article discloses a method and system that can combine the above two processes, NF discovery and application layer service discovery. In other words, a mechanism for integrating application layer service discovery with network function discovery (ie, network service discovery) in a mobile core network is proposed.

[0176] In one aspect, a method is disclosed that allows UEs and application servers to advertise their services within a core network to make device / SCS / AS service capabilities discoverable;

[0177] In another aspect, a method for a UE to initiate device / SCS / AS service discovery in a core network through (i) a registration procedure and (ii) a PDU session establishment procedure is disclosed.

[0178] On the other hand, a method for a UE to subscribe to a certain device / SCS / AS service capability in a core network is disclosed.

[0179] In yet another aspect, a method for an SCS / AS to initiate a device / SCS / AS service discovery process in a core network is disclosed.

[0180] Configuration to enable service discovery in the core network

[0181] The following describes a method for a UE and an application server to announce or provide their service capability information to a core network so that other entities (eg, UE and NF) can initiate a service discovery process within the core network.

[0182] To enable service discovery within the core network, the UE and SCS / AS need to interact with the NRF which performs the discovery process. The service capability information may be stored at the UDM / UDR / UDSF or alternatively at the NRF.

[0183] Fig.12 An example protocol stack is shown that illustrates how the UE utilizes a NAS connection to transfer service capability information to / from the core network and initiates a service discovery process at the NRF. Messages related to service discovery are transferred over the N1 NAS connection between the UE and the AMF. The service discovery includes device / SCS / AS services and network services.

[0184] The UE can use this protocol stack to send its own service capability information to the core network so that other UEs and / or AFs can discover it. In addition, the UE can use this protocol stack to send discovery requests to the network and receive discovery results from the network. Fig.12 It is shown that the request may terminate at the NRF, but it may alternatively terminate at the UDM / UDR.

[0185] Service Capability Information Elements in Core Networks

[0186] The service capability information provided by the UE or SCS / AS may be stored in the UDM / UDR / UDSF. Fig.12 The protocol stack can be used to send discovery information to the NRF, and the NRF can store the information in the UDM / UDR. Alternatively, the information can be stored locally in the NRF or in the UDM / UDR / UDSF associated with the NRF. A new information element can be created to store information about service capabilities. The service capabilities can include the information listed in Table 2.

[0187] Table 2: Service capability information maintained in core network functions

[0188]

[0189] UE announces service capabilities

[0190] Fig.13 is a call flow illustrating a method by which a UE can advertise its device / SCS / AS service capability information. This method can occur with a registration, service request, or session management process.

[0191] In step 1, the UE may send information about the service capabilities it supports to the AMF. This information may be included in a NAS message (e.g., an initial registration request, a registration update, a service request message, a PDU session establishment request, a session modification, or a session release request). In addition to the service capability information listed in Table 2, the location where the service capability information is stored in the core network may also be included. Such a location may be identified using the address / ID of a UDR / UDM, UDSF, or even an NRF. If the UE does not specify a location, the core network entity may use a default location that may be pre-configured.

[0192] In step 2, the AMF contacts the UDM / UDR to verify whether the UE is allowed to advertise its service capabilities and is eligible to provide any service capabilities through the core network. Alternatively, the AMF can check the policy stored in the PCF to determine whether the UE is allowed to advertise its capabilities. In order to reach the appropriate PCF, the AMF can directly store the PCF ID of the service UE, or the AMF obtains the PCF information from the UDM based on the UE ID and subscription information.

[0193] In step 3, once the verification is completed, the AMF forwards the request to the NRF. The information listed in Table 2 may be delivered.

[0194] In step 4, the NRF stores the information locally or in the UDM / UDR. The information can be stored in any suitable data structure, such as a table or a non-relational database. The UE ID (e.g., 5G-GUTI, SUPI) can be used to link the information with the UE providing the service capabilities.

[0195] In step 5, the NRF sends a response to the UE via the AMF, which includes an address (e.g., URI) for accessing the service capability information. If needed at a later time, this address allows the UE to update or delete this information by directly contacting the NRF.

[0196] At the same time, in step 6, the NRF notifies other NFs that have subscribed to notifications about new services that there is a new service capability added using the address to access this information. In other words, the new service capability is registered at the NRF, and when this type of service capability is registered, the NRF sends a notification to any NF that requires notification. In addition, when this type of service capability is available through the core network, the NRF can notify the UE that requires notification.

[0197] SCS / AS notification service capability

[0198] The SCS / AS may also advertise its equipment / SCS / AS service capabilities within the core network. Fig.14 is a call flow diagram illustrating one example of a method in which an SCS / AS may advertise its device / SCS / AS service capabilities within a core network.

[0199] As shown in the figure, in step 1, the SCS / AS may send its service capability information to the NEF to make it discoverable in the core network. In addition to the information listed in Table 2, the following information may also be included: (i) an indication of whether the information is discoverable for non-3GPP UEs or roaming UEs; and (ii) the address or identifier (ID) of the UDR / UDM that will store the information.

[0200] In step 2, the NEF contacts the UDR / UDM to verify whether the SCS / AS is allowed to advertise its service capabilities and is eligible to provide service capabilities through the core network. Alternatively, the NEF can check this against the policy by querying the PCF.

[0201] In step 3, once the verification is completed, the NEF sends a request to the NRF, where the NRF will store the service capability information.

[0202] In step 4, NRF is similar to the above Fig.13 Step 4 discussed the way to store service capability information.

[0203] In step 5, the NRF sends a response to the SCS / AS via the NEF, including the ID of the UDR / UDM and the address (eg, URI) of the service capability information.

[0204] In step 6, when this type of service capability is added, the NRF notifies the UE and / or other NFs that require notification, and the NRF will make it discoverable in the future. In addition, the NRF may also notify the SCS / AS that requires notification.

[0205] When storing service capability information (such as device type), NRF may also involve certain device / application server information. The discovery request can also be combined with information about the device / AS making the request to better tailor the response.

[0206] Alternatively, the SCS / AS may only inform the core network that it provides a service discovery function for the service capability list, so that the core network can later direct the UE to the SCS / AS to perform service discovery when the UE registers with the network. Moreover, the core network can intelligently forward the service discovery request to the SCS / AS to further process the request and perform service discovery. To this end, the core network entity needs to store the abstract service capability information and select the SCS / AS based on such information. When the core network receives a response from the selected SCS / AS, it can process the response and forward it back to the UE.

[0207] Another alternative way for the core network to obtain service capability information is that the core network entity (e.g., NRF) can actively or periodically update the service capability information by communicating with SCS / AS via NEF. In this way, the discovery result can be more accurate and up-to-date.

[0208] UE-initiated service discovery in the core network

[0209] The following describes a method for device / SCS / AS service discovery initiated by a UE. The method may be triggered together with a NAS message such as a registration procedure, a PDU session establishment procedure or a service request.

[0210] The service discovery results may affect certain NF selections, such as network slice selection, AMF selection, SMF selection, UPF selection, and SCS / AS (i.e., DN) selection.

[0211] Service discovery as part of the registration process

[0212] Fig.15 is a call flow illustrating a method by which a UE may initiate service discovery as part of a registration procedure, such as the registration procedure defined in 3GPP TS 23.502; Procedures for 5G Systems; Stage 2, v0.5.0, Release 15. Fig.15 The figure illustrates how the steps of the registration procedure of 3GPP TS 23.502 can be modified to allow the UE to initiate the service discovery process together with the general registration procedure. Fig.15 In the example of , modifications may be applied to steps 1, 3, 9, and 21-22, and new steps may also be added.

[0213] As shown, in step 1, the UE may indicate in the registration request message that it wants to initiate service discovery, including providing information related to the (one or more) service capabilities that the UE is requesting to discover (i.e., the criteria for discovery), for example, the UE may indicate in the request a service capability ID, a service type, and / or a service provider ID to guide service discovery. The UE may also include some or all of the information listed in Table 2. In addition, the UE may also indicate that it wants the discovery process to include more than one aspect, for example, to perform service discovery (e.g., intelligent transport services) and network function discovery (e.g., network data analysis function (NWDAF)). The UE may also include the external ID it uses in the service domain, i.e., the ID assigned within the service layer. This can be used to verify whether the UE is allowed to discover or use a certain service capability - because when the service capability information is stored in the core network, the service provider may indicate that the service is open to some clients identified by the external ID. In addition, the UE may indicate whether the service discovery result affects the operation during registration - for example, whether the network slice selection depends on whether the desired service capability is discovered. The UE may also indicate the scope of the service discovery that the UE wishes to apply to the service discovery performed, such as, for example, if the UE is roaming, only the NRF in the home PLMN, or the NRF in the home PLMN and the visited PLMN. The UE may also indicate that it wants to subscribe to certain service capabilities at the NRF, where the service capability information is such as some or all of the information listed in Table 2. For example, refer to Fig.11 For the use case shown in FIG. 1 , a UE (such as UE1) may include the following information in a request to trigger service discovery:

[0214] Service Type: Environmental Monitoring

[0215] Service capability ID: environment_monitoring_123

[0216] Service Provider ID: SP-abc

[0217] Service area: Tracking area xxx

[0218] Supported API: REST

[0219] In step 2, an AMF function is selected to serve the UE.

[0220] In step 3, the information related to service discovery in step 1 is sent from the RAN to the AMF.

[0221] In step 4-5, in the case where the UE is served by the new AMF, the newly selected AMF contacts the old AMF to obtain the UE context information. That is, in the case where the UE is served by an AMF different from the old AMF.

[0222] In steps 6-7, the new AMF obtains additional identity information from the UE.

[0223] In step 8, the AMF may decide to initiate UE authentication by invoking the AUSF.

[0224] In step 9, during policy association, the AMF may query the UDM / UDR to determine whether the UE is allowed to trigger service discovery or subscribe to certain service capabilities within the core network. Authorization may be specific to one service capability, for example, in the case where the UE wants to discover device management and remote monitoring services in a smart home application, and different policies may be formulated as to whether the UE is allowed to discover each service capability.

[0225] In step 10, the new AMF notifies the old AMF that the UE's registration with the new AMF is complete by calling the Namf_Communication_RegistrationCompleteNotify service operation.

[0226] In step 11, the new AMF sends an Identity Request / Response (PEI) to the UE.

[0227] In step 12, optionally, the new AMF initiates a ME identity check by calling the N5g-eir_EquipmentIdentityCheck_Get service operation.

[0228] In step 13, if step 14 is to be performed, the new AMF selects a UDM based on the Subscription Permanent Identifier (SUPI), and then the UDM may select a UDR instance.

[0229] In steps 14a-b, if the AMF has changed since the last registration procedure, or if the UE provides a SUPI that does not refer to a valid context in the AMF, or if the UE registers to the same AMF with which it is already registered for non-3GPP access (i.e. the UE is registering over non-3GPP access and initiates this registration procedure to add 3GPP access), then the new AMF registers with the UDM using Nudm_UECM_Registration and subscribes to be notified when the UDM deregisters the AMF.

[0230] In step 14c, as indicated in step 14a, when the UDM stores the associated access type (e.g., 3GPP) with the serving AMF, it will cause the UDM to initiate a Nudm_UECM_DeregistrationNotification to the old AMF corresponding to the same (e.g., 3GPP) access (if any).

[0231] In step 14d, the old AMF uses Nudm_SDM_unsubscribe to cancel the subscription data to the UDM.

[0232] In step 15, the AMF selects the PCF, for example, if the AMF decides to initiate PCF communication, the AMF has not yet obtained the access and mobility policy for the UE, or if the access and mobility policy in the AMF is no longer valid.

[0233] In step 16, the new AMF performs policy association establishment.

[0234] In step 17, the PCF may call the Namf_EventExposure_Subscribe service operation for the UE event subscription.

[0235] In step 18, AMF may send a Nsmf_PDUSession_UpdateSMContext() message to SMF.

[0236] In step 19, the new AMF may send an N2 AMF mobility request to the N3IWF.

[0237] In step 20, the N3IWF may send an N2 AMF mobility response to the new AMF.

[0238] In steps 21-22, in the response to the UE, the AMF may include information of any discovered service capabilities that meet the search criteria provided by the UE in the request, such as some or all of the information listed in Table 2. Alternatively, if the UE has requested to subscribe to certain service capabilities at the NRF, the AMF may indicate a successful subscription. In this case, the AMF may include a subscription ID, a notification target address, and an NRFID.

[0239] In an alternative embodiment, the core network may indicate in the registration accept message that service discovery functionality is available in the network slice serving the UE - so that the UE can initiate service discovery after registration is complete.

[0240] Note that after the AMF obtains authorization to allow the UE to request service discovery in the core network, new steps may be required between the AMF and the NRF. This authorization process may be performed in step 9 and / or step 16, where the AMF may send the desired service capability information received from the UE to the NRF.

[0241] In the event that AMF reallocation is required during registration, as specified in section 4.2.2.2.3 of 3GPP TS 23.502, Procedures for 5G Systems; Stage 2, v0.5.0, Release 15, similar information may be provided to enable service discovery as discussed in the general registration process above.

[0242] Fig.16 3GPP TS23.502, Procedures for 5G Systems; Phase 2, v0.5.0, Version 15, is a call flow illustrating how the AMF reallocation procedure can be modified to enable the AMF to insert service capability information and trigger a service discovery process. Specifically, in one embodiment, in step 6a, the AMF may insert the service capability information and trigger the service discovery process together with the NF discovery request message. Alternatively, the AMF may send a new separate service discovery request message to the NRF. In an embodiment, the NRF may be responsible for performing the service discovery process. The NRF may perform a search based on the search criteria information in the request message (i.e., some or all of the information listed in Table 2 for each desired service capability to be discovered) by comparing the search criteria with the stored information related to the available service capabilities that have been announced to the NRF or otherwise made known to the NRF. If any known service capability meets the search criteria, then the NRF may return information for each such service capability, including, for example, an identifier of the service capability provider and information indicating the area in which the service is provided. When the request is received from the AMF, the NRF may perform service capability discovery together with NF discovery. For NF discovery, the NRF may perform a search based on the registration information and subscription information of the UE. For example, based on the requested NF type or NF service or the registration area assigned to the UE, the NRF may identify the appropriate NF and include information about the NF in the discovery result provided in the response message. The NF discovery request and NF discovery process may be performed according to the specifications of 3GPP TS 23.501 and TS 23.502.

[0243] Service discovery as part of PDU session establishment

[0244] According to another aspect, the session establishment process can be modified so that the UE can trigger device / SCS / AS service discovery when initiating session establishment. In one embodiment, the service discovery process can be performed during SMF selection, which will be triggered as a sub-process of the session establishment process.

[0245] Fig.17is a call flow illustrating a method by which a UE may initiate service discovery as part of a UE initiated session establishment procedure, such as a PDU Session Establishment Procedure defined in 3GPP TS 23.502, Procedure for 5G Systems; Stage 2, v0.5.0, Release 15. Fig.17 The figure illustrates how the steps of the PDU Session Establishment procedure of 3GPP TS23.502 can be modified to allow the UE to initiate a service discovery process together with the PDU Session Establishment procedure. Fig.17 In the example of , the modifications may apply in particular to steps 1, 2, 3a, 4, 8 and 12-13.

[0246] like Fig.17 As shown in FIG, in step 1, the UE may indicate that it wishes to start a service discovery process before establishing a PDU session. This indication may be provided in a service discovery signal encapsulated as a payload within a NAS mobility management (MM) message. Thus, the service discovery information is carried within a NAS MM message (e.g., Fig.12 ).

[0247] As part of the signal, the UE may provide information about the service capabilities it wants to discover (i.e., the criteria filters for discovery), such as some or all of the information listed in Table 2 for the desired service capabilities. In addition, the UE may include some or all of the following information:

[0248] The external ID of the UE in the service domain, i.e., the ID assigned within the service layer;

[0249] An indication of whether the service discovery results will be considered in the SMF selection process;

[0250] An indication of whether service discovery is independent of the session establishment process, i.e., the discovery results will not affect the session establishment process;

[0251] Instead of specifying the destination DN to which the UE wants to connect, the UE may provide an indication that it wants the core network to determine the destination DN based on the service discovery results; in this case, the UE does not set the PDU Type parameter;

[0252] In the event that the UE attempts to reactivate an existing session identified by a session ID, the UE may provide an indication to the core network whether a different DN found through service discovery may be associated with the existing session; and

[0253] An indication that the UE wants to subscribe to a certain service capability(s) at the NRF. For example, see Fig.11 For the use case shown in FIG. 1 , a UE (such as UE1) may include the following information in a request to trigger service discovery:

[0254] Service Type: Environmental Monitoring

[0255] Service capability ID: environment_monitoring_123

[0256] Service Provider ID: SP-abc

[0257] Service area: Tracking area xxx

[0258] Supported API: REST

[0259] In step 2, during SMF selection, a discovery process is performed - details of which are in Fig.18 and described below.

[0260] In step 3a, the AMF may include the address of the DN resulting from the service discovery process in the message to the SMF, and may also indicate to the SMF that the DN was discovered by the NRF - and may be different from the original DN specified by the UE. In addition, in the case where the SMF is selected based on the service discovery process, the AMF may include service capability information.

[0261] In step 4, in case the UE is using service capabilities through the core network and PDU session, the SMF may update the UE's subscription / registration information by including the service capability information.

[0262] In step 5, depending on the request received in step 3a, the SMF may send a Nsmf_PDUSession_CreateSMContext Response (cause, SM context ID or N1 SM container (PDU Session Reject (cause))) or a Nsmf_PDUSession_UpdateSMContext Response to the AMF.

[0263] In step 6, an optional secondary authorization / authentication may be performed.

[0264] In step 7a, if dynamic PCC is deployed, the SMF performs PCF selection.

[0265] In step 7b, the SMF may perform a session management policy establishment process to establish a PDU session with the PCF and obtain the default PCC rules for the PDU session.

[0266] In step 8, if the UE does not specify the PDU session type and the DN is determined based on the service discovery process, the SMF determines the type of PDU session in this step and selects the UPF accordingly.

[0267] In step 9, the SMF may perform the session management policy modification procedure as defined in section 4.16.5 to report a certain event to the previously subscribed PCF.

[0268] In step 10, if the request type indicates "initial request", the SMF initiates the N4 session establishment procedure with the selected UPF, otherwise it initiates the N4 session modification procedure with the selected UPF.

[0269] In step 11, SMF sends a Namf_Communication_N1N2MessageTransfer message to AMF.

[0270] In steps 12-13, the AMF returns the result of the session establishment process and the service discovery result to the UE via the RAN. In particular, if the DN and PDU session type information are determined based on the service discovery process, then they are included, and the service capability information listed in Table 2 from the service discovery process is also included.

[0271] In step 14, the (R)AN sends an N2 PDU Session Response to the AMF.

[0272] In step 15, AMF sends a Nsmf_PDUSession_UpdateSMContext request (N2 SM information, request type) to SMF. AMF forwards the N2 SM information received from (R)AN to SMF.

[0273] In step 16a, SMF and UPF initiate the N4 session modification process. SMF provides AN tunnel information and corresponding forwarding rules to UPF.

[0274] In step 16b, the UPF provides an N4 session modification response to the SMF.

[0275] In step 17, SMF sends a Nsmf_PDUSession_UpdateSMContext response (cause) to AMF.

[0276] In step 18, SMF sends Nsmf_PDUSession_SMContextStatusNotify(release) to AMF.

[0277] In step 19, the SMF sends a router advertisement to the UE via the UPF. Specifically, when the PDU type is IPv6 or IPv4v6, the SMF generates an IPv6 router advertisement and sends it to the UE via the N4 interface and the UPF.

[0278] In step 20, if the PDU session establishment fails after step 4, the SMF shall (i) unsubscribe from the modification of the session management subscription data of the corresponding (SUPI, DNN, S-NSSAI) using Nudm_SDM_Unsubscribe if the SMF no longer handles the UE's PDU session for this (DNN, S-NSSAI), and (ii) deregister for the given PDU session using Nudm_UECM_Deregistration (SUPI, DNN, PDU Session ID).

[0279] Fig.18 is a call flow illustrating a method by which service discovery may be performed as part of an SMF selection process, such as the SMF selection process defined in 3GPP TS 23.502, Procedure for 5G Systems; Stage 2, v0.5.0, Release 15. Fig.18 Illustrate how the steps of the SMF selection procedure of 3GPP TS 23.502 can be modified to allow service discovery during the SMF selection procedure. Fig.18 In the example of , the modifications may apply in particular to steps 3 and 4.

[0280] exist Fig.18 After the slice selection request and response steps 1 and 2, Fig.18 In step 3 (such as Fig.17 1), the UE may indicate that it wants to initiate a service discovery process in a Session Establishment Request message. The AMF may forward this indication to the NRF along with the service capability information (i.e., criteria for discovery) that it wants to discover (such as some or all of the information listed in Table 2 for each desired service capability). The NF Discovery Request sent from the AMF may be combined with a Service Capability Discovery Request, indicating that the request covers NF discovery as well as service discovery. The information included in the request message may come from the UE's request (e.g., Fig.15 The registration request and Fig.17) or UE context information stored at the AMF. The NRF can perform both service capability discovery and NF discovery. For service capability discovery, the NRF can perform a search based on the information in the request message (i.e., some or all of the information for each desired service capability listed in Table 2) by comparing the search criteria with the stored information related to the available service capabilities that have been notified to the NRF or otherwise made known to the NRF. If any known service capability meets the search criteria, the NRF can return information for each such service capability, which includes, for example, an identifier of the service capability provider and information indicating the area in which the service is provided. For NF discovery, the NRF can perform a search based on the registration information and subscription information of the UE. For example, based on the requested NF type or NF service or the registration area assigned to the UE, the NRF can identify the appropriate NF and include information about the NF in the discovery results provided in the response message. The NF discovery request and NF discovery processing can be performed according to the specifications of 3GPP TS23.501 and TS23.502.

[0281] exist Fig.18 In step 4, NRF returns the result of service capability discovery (and NF discovery), indicating whether the desired (one or more) service capabilities or NFs are found. If such (one or more) service capabilities or NFs are found and available, then information about each discovered service capability or NF is returned.

[0282] Alternatively, if the service discovery is independent of the session establishment process, i.e., the result will not affect any operation of establishing a PDU session, then the AMF can initiate service discovery at the NRF by using the new NRF service presented below. In the case where the UE wants to subscribe to certain service capabilities at the NRF, the AMF can also send a separate subscription request message to the NRF using the new NRF service presented below.

[0283] UE subscribes to a specific service

[0284] In addition to the one-time request / response model for device / SCS / AS service discovery, the UE can also subscribe to specific device / SCS / AS service capabilities that are not available through the core network and get notified through the NRF once the service capabilities are available. The service capabilities can be provided by the application server or the device. Fig.19 is a call flow illustrating one embodiment of a method by which a UE may subscribe to such device / SCS / AS service capabilities.

[0285] like Fig.19As shown in , in step 1, the UE sends a subscription request to the AMF, indicating that it is interested in a certain service capability. In addition to some or all of the information listed in Table 2 for each desired service capability, the UE may also include the ID or address of the entity that is the target of the notification. A different entity than the UE that initiates the request may be the target of the notification. For example, the notification target may be a remote UE, an IoT device without a 3GPP subscription, or an application server (AS).

[0286] In step 2, the AMF contacts the UDM / UDR to verify that the requesting UE and the notification target are allowed to use the service discovery service and receive notifications. In the case where the notification target is not subscribed or has not yet registered with the network, the network can set the requesting UE as the notification target. Alternatively, the AMF can contact the PCF for verification processing.

[0287] In step 3, after completing the verification, the AMF may forward the subscription request to the NRF.

[0288] In step 4, the NRF sends a response to the UE via the AMF. The subscription ID may be included as a reference.

[0289] In step 5, when a new service capability is added at the NRF that matches the subscriber's interests (i.e., the criteria provided in the subscription request in step 1), the NRF may issue a notification including the subscription ID and the ID of the entity providing the new service capability (e.g., SCS / AS or UE), as well as some or all of the information listed in Table 2 for that service capability.

[0290] Service discovery initiated by application servers in the core network

[0291] As combined Fig.11 As discussed in the use case of , an application server may look for some devices that can provide some application service data. According to another aspect disclosed herein, the application server may communicate with the NRF to perform such discovery in one of two ways: (1) by directly requesting to trigger the discovery process at the NRF, and (2) by creating a subscription at the NRF so that when some UE advertises service(s) and capability(s) that match the interest of the application server, the NRF will send a notification to the SCS / AS.

[0292] Fig. 20 is a call flow illustrating one embodiment of a method for service discovery initiated by an SCS / AS in a network.

[0293] As shown in the figure, in step 1, the SCS / AS sends a service discovery request message to the NEF. In addition to providing some or all of the service capability information listed in Table 2 for each desired service capability, the following information may also be included:

[0294] An indication of the service provider's device type, such as, for example, UE, cloud server, or local server;

[0295] An indication of whether the SCS / AS wants to trigger a service discovery process or subscribe to a service capability notification; and

[0296] • Additional information that the SCS / AS may want to return, such as the address of the NRF that performs service discovery and the location that stores service capability information (e.g., the address of the UDR / UDM).

[0297] In step 2, the NEF communicates with the PCF for authorization to determine whether the SCS / AS is allowed to use the service discovery service and discover the desired service capabilities.

[0298] In step 3, NEF sends a service discovery request to NRF.

[0299] In steps 4-5, NRF performs service discovery and returns a response.

[0300] It should be understood that the execution Figure 12-20 The entities of the steps shown in the figure, such as UE, AMF, UDR / UDSF, UDM / UDR, NRF, NEF, PCF, NF, SCS / AS, (R)AN, SMF, AUSF, NSSF, DN, etc., may be stored in a manner such as Figure 2 or Figure 7 A logical entity implemented in the form of software (i.e., computer executable instructions) in the memory of a computer system or a device configured for wireless and / or network communication and executed on its processor. That is, Figure 12-20 The method(s) shown in the embodiment may be stored in a device such as Figure 2 or Figure 7 The computer system or device shown in the figure is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system, which, when executed by the processor of the device, performs Figure 12-20 It should also be understood that Figure 12-20 The functions shown in can be implemented as a set of virtualized network functions. The network functions do not necessarily have to communicate directly, but they can communicate via forwarding or routing functions. It should also be understood that Figure 12-20 Any transmission and reception steps shown in can be performed by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed therein.

[0301] New NRF Services

[0302] Service Capacity Management

[0303] According to yet another aspect of the present disclosure, a new Network Repository Function (NRF) is disclosed - named Nnfr_ServiceCapabilityManagement - whose function is to manage device / SCS / AS service capabilities within the core network (i.e., register, update, or delete). This service allows the NRF to manage the service capability information of UE and SCS / AS and enable service discovery in the core network. Table 3 describes the new NRF service. As an example of how the new service can be used, in Fig.13 In step 3 of , AMF can call Nnrf_ServiceCapabilityManagement_ServiceCapabilityRegister operation to request NRF to register new service capabilities for UE. Fig.14 Call the same operation as in step 3 of .

[0304] Table 3: “Device / SCS / AS Service Capability Management” services provided by NRF

[0305]

[0306] Service Capability Discovery

[0307] According to yet another aspect of the present disclosure, a new Network Repository Function (NRF) is disclosed - named Nnrf_ServiceCapabilityDiscovery - whose function is to enable device / SCS / AS service discovery within the core network. In this embodiment, the new service performs service discovery at the NRF. Table 4 describes the new NRF service. As an example of how the new service can be used, in Fig.18 In step 3, AMF can call Nnrf_ServiceCapabilityDiscovery_ServiceCapabilityDiscovery to request NRF to perform service discovery processing.

[0308] Table 3: “Device / SCS / AS Service Capability Discovery” services provided by NRF

[0309]

[0310]

[0311] user interface

[0312] Fig.21An exemplary user interface that can be used to configure device / SCS / AS service discovery in a 5G network is shown. The user interface can be presented by a terminal device (such as a UE) or a service application (SCS / AS) as a service provider or service consumer. For example, the user interface can be displayed on Figure 2 and Figure 7 on display 128 or 86.

[0313] The illustrations of various aspects described herein are intended to provide a general understanding of the structure, function and operation of various aspects. These illustrations are not intended to be used as a complete description of all elements and features of the device and system utilizing the structure or method described herein. After consulting this disclosure, many other aspects may be clear to those skilled in the art. Other aspects of the disclosure may be utilized and derived from this disclosure, so that structural and logical replacement and changes may be performed without departing from the scope of the disclosure. Thus, this disclosure and the accompanying drawings should be considered to be illustrative and not restrictive.

[0314] The description of these aspects is provided to enable making or using these aspects. Various modifications to these aspects will be apparent, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but should be given the widest possible scope consistent with the principles and novel features as defined in the following claims.

Claims

1. A method comprising: receiving, by a network function (NF) of a core network, a session establishment request from a wireless transmit / receive unit (WTRU), wherein the session establishment request includes an indication to trigger a service discovery process; Based on the indication triggering the service discovery process, the NF sends a service capability discovery request to the Network Repository Function (NRF); In response to the service capability discovery request, the NF receives a service capability message from the NRF; as well as A message is sent by the NF to the WTRU, the message including one or more service capabilities received in a service capability message in response to a session establishment request.

2. The method of claim 1, wherein the session establishment request comprises a protocol data unit (PDU) session establishment message. The method of claim 1 , wherein the indication triggering the service discovery process comprises one or more service capability criteria. The method of claim 1 , wherein the service capability discovery request further comprises one or more criteria for service capabilities for the service discovery process.

5. The method of claim 4, wherein the one or more criteria of service capability include: An indication of a network service type associated with the service capability, an identifier of a service capability provider, an indication of a geographic region in which the WTRU is allowed to subscribe to the service capability, or a combination thereof.

6. The method of claim 1, wherein the message further comprises: One or more constraints associated with providing the corresponding one or more service capabilities, one or more requirements associated with providing the corresponding one or more service capabilities, or both.

7. The method of claim 1, wherein the service capability message includes information indicating one or more services provided by a core network.

8. The method of claim 1, wherein the message further includes protocol data unit (PDU) session type information for establishing the requested session.

9. A device for implementing a network function (NF) of a core network, the device comprising: processor; and computer executable instructions, which, when executed by the processor, cause the apparatus to perform the following operations: receiving a session establishment request from a wireless transmit / receive unit (WTRU), wherein the session establishment request includes an indication to trigger a service discovery process; sending a service capability discovery request to a network repository function (NRF) based on the indication triggering the service discovery process; receiving a service capability message from the NRF in response to the service capability discovery request; as well as A message is sent to the WTRU, the message including one or more service capabilities received in a service capabilities message in response to a session establishment request.

10. The apparatus of claim 9, wherein the session establishment request comprises a protocol data unit (PDU) session establishment message.

11. The apparatus of claim 9, wherein the indication triggering the service discovery process comprises one or more service capability criteria.

12. The apparatus of claim 9, wherein the service capability discovery request further comprises one or more criteria for service capabilities for service discovery processing.

13. The apparatus of claim 12, wherein the one or more criteria of service capability include: An indication of a network service type associated with the service capability, an identifier of a service capability provider, an indication of a geographic region in which the WTRU is allowed to subscribe to the service capability, or a combination thereof.

14. The apparatus of claim 9, wherein the message further comprises: One or more constraints associated with providing the corresponding one or more service capabilities, one or more requirements associated with providing the corresponding one or more service capabilities, or both.

15. The apparatus of claim 9, wherein the service capability message comprises information indicating one or more services provided by a core network.

16. The apparatus of claim 9, wherein the message further includes protocol data unit (PDU) session type information for establishing the requested session.

17. A wireless transmit / receive unit (WTRU), comprising a processor, the processor configured to: Sending a session establishment request to a network function (NF), wherein the session establishment request includes an indication for triggering the NF to perform service discovery; and In response to a session establishment request, a message including one or more service capabilities is received from the NF, wherein the one or more service capabilities are retrieved by the NF from a network repository function (NRF) in response to a service capability discovery request, wherein the service capability discovery request is sent by the NF based on the indication included in the session establishment request.

18. The WTRU of claim 17, wherein the session establishment request comprises a protocol data unit (PDU) session establishment request.

19. The WTRU of claim 17, wherein the indication for triggering the NF to perform service discovery comprises one or more service capability criteria.

20. The WTRU of claim 17, wherein the message received from the NF in response to a session establishment request further comprises: One or more constraints associated with providing the corresponding one or more service capabilities, one or more requirements associated with providing the corresponding one or more service capabilities, or both.

21. An apparatus comprising a processor, wherein the processor is configured to: sending a subscription request to a network function (NF), wherein the subscription request indicates a request to be notified when one or more NFs become available; A notification is received from the NF, wherein the notification indicates that the one or more NFs have become available.

22. The apparatus of claim 21, wherein the processor is configured to send the subscription request based on receiving a message from a wireless transmit / receive unit (WTRU), wherein the message indicates that the WTRU wants to subscribe to the one or more NFs.

23. The apparatus of claim 22, wherein the processor is configured to send a message to the WTRU indicating that the one or more NFs have become available.

Images