A method for node communication

Abstract

Methods, systems, and apparatuses are provided for communicating between a first node and a second node via a service communication proxy (SCP). A stream control transmission protocol (SCTP) interface is established between the first node and the SCP. Communication occurs between the first node and the SCP via the established SCTP interface. Communication occurs between the second node and the SCP via a service-based interface (SBI). The first node does not support the SBI. The second node supports the SBI.

Description

A METHOD FOR NODE COMMUNICATIONTECHNICAL FIELD

[0001] The present subject matter is directed generally to wireless communications. Particularly, the present subject matter relates to methods, devices, and systems for improving communication between nodes in a wireless network.BACKGROUND

[0002] The 3GPP-defined 5G core network introduces a Service-Based Interface (SBI) that uses HTTP (HTTP / 2) as the communication protocol. The service-based architecture is based on Network Functions (NF) , where one NF provides services to other NFs through the SBI. Currently, many nodes of the 5G Core Network (CN) support the SBI interface.

[0003] The SBI interface has the advantage of flexible software customization. In the future, the 5G Radio Access Network (RAN) may also introduce the SBI interface; for example, Cloud RAN may allow RAN nodes to access or provide services based on the SBI interface. However, this may cause earlier deployed legacy RAN nodes that and do not support the SBI interface to be unable to communicate either with RAN nodes or 5G core network nodes that only support the SBI interface. This could lead to the entire RAN network being unable to function normally.SUMMARY

[0004] The present subject matter invention mainly provides a method for enabling indirect communication between communication nodes that support SBI and those that do not.

[0005] In some examples, a method for communicating between a first node and a second node via a service communication proxy (SCP) includes establishing a stream control transmission protocol (SCTP) interface between the first node and the SCP; communicating between the first node and the SCP via the established SCTP interface; and communicating between the second node and the SCP via a service-based interface (SBI) , wherein the first node does not support the SBI, and the second node supports the SBI.

[0006] In some examples, a system for wirelessly communicating between a first node and a second node via a service communication proxy (SCP) , includes a processor; and a memory in communication with the processor, the memory storing instructions executable by the processor to configure the system to: establish a  stream control transmission protocol (SCTP) interface between the first node and the SCP; communicate between the first node and the SCP via the established SCTP interface; and communicate between the second node and the SCP via a service-based interface (SBI) , wherein the first node does not support the SBI, and the second node supports the SBI.

[0007] In some other examples, an apparatus for wireless communication may include a memory storing instructions and a processing circuitry in communication with the memory. When the processing circuitry executes the instructions, the processing circuitry is configured to carry out the above methods.

[0008] In some other examples, a device for wireless communication may include a memory storing instructions and a processing circuitry in communication with the memory. When the processing circuitry executes the instructions, the processing circuitry is configured to carry out the above methods.

[0009] In some other examples, a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the above methods.

[0010] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows an example of a wireless communication system include one wireless base stations and one or more user equipment.

[0012] FIG. 2 shows an example of a base station (gNB) .

[0013] FIG. 3 shows an example of a user equipment (UE) .

[0014] FIG. 4 shows an example technique to establish a connection over SCTP between a first communication node and an SCP node in accordance with the present subject matter.

[0015] FIG. 5 shows an example technique to enable a first communication node not supporting SBI to send an NF registration request over the S interface to register its NF in the NRF via the SCP in accordance with the present subject matter.

[0016] FIG. 6 shows an example technique of how a communication node that does not support SBI discovers a set of NFs provided by one or more other nodes in accordance with the present subject matter.

[0017] FIG. 7 shows an example technique to facilitate communication between a communication node that supports SBI and another communication node that does not in accordance with the present subject matter.

[0018] FIG. 8 shows an example technique to enable a communication node not supporting SBI to  send an NF update request over the S interface to update its NF registered in the NRF via the SCP in accordance with the present subject matter.

[0019] FIG. 9 shows an example communication between the UE and the NW to illustrate the UE reporting within a prediction window.DETAILED DESCRIPTION

[0020] The 3GPP defines a Service-Based Architecture (SBA) for 5G Core Network (CN) . SBA provides a cloud-native service framework in which CN functionalities (authentication, mobility management, etc. ) are supported by Network Functions (NFs) , self-contained software applications that may be run on commercial off-the-shelf hardware hosted by cloud infrastructure.

[0021] Interconnected on a logically shared infrastructure or service bus, NFs may offer services accessible to any other authorized NF through APIs (Application Programming Interfaces) named service-based interfaces (SBI) . Services exposed by an NF (service producer) to another NF (service consumer) may be described using API specifications that identify the set of accessible service data and indicate the authorized operations on these service data.

[0022] SBI messaging between various 5GC NFs may be via hypertext transfer protocol (HTTP / HTTP2) . Any NF may use the services another NF provides, and it may also be possible to connect to other NFs without introducing specific new protocols or interfaces, but rather based on HTPP. This enables a more flexible development of services, as well as a more flexible way to connect to a new NF type. Thus, 3GPP core networks have gone from 4G telecom-style protocol interfaces to 5G web-based APIs.

[0023] 3GPP selected OpenAPI as the formal language to be used for the definition of Web-based APIs in the Service-Based Architecture. As indicated in 3GPP TS 29.501, each API is documented in a 3GPP technical specification (TS) that describes in natural language the API, and this specification also includes a normative Annex containing an OpenAPI description of the API. An OpenAPI description defines a standard, programming language-agnostic interface specification for HTTP APIs.

[0024] In this service platform, every NF may expose services and consume services provided by other NF. Since NFs are loosely coupled and interfaced with APIs, they may be easily deployed anywhere, on demand, without impact on the existing ones. New services or service instances may be published in a centralized repository, the Network Repository Function (NRF) , which may be accessible to all the NFs to discover the services available in the network and may retrieve required routing information to interact with the NFs supporting the services.

[0025] For the communication between NFs, 3GPP supports direct and indirect scenarios between a Consumer NF and a Producer NF. In order to support indirect communication, SCP (Service Communications Proxy) is introduced in 5G core network, and supports communication indirect via the SCP by routing SBI messages over SBI interface between service consumers and producers.

[0026] The current Radio Access Network (RAN) nodes, e.g, gNB, gNB-CU, gNB-DU, gNB-CU-UP, gNB-CU-CP, which do not support SBI, but use point-to-point connections established over Stream Control Transmission Protocol (SCTP) for control plane signaling. The control plane messages within the RAN are SCTP messages. Depending on the specific 3GPP interface, a variety of SCTP message types exist, including but not limited to XNAP, X2AP, NGAP, F1AP, and E1AP. The RAN node may be viewed as a service provider, offering a range of services such as interface management, mobility management, UE context management, and connection management. However, these services are all executed / provided by the nodes based on notifications received through SCTP messages. The corresponding behavior of a receiver node as specified in the 3GPP specification. ASN. 1 (Abstract Syntax Notation One) is a powerful language used in 3GPP specifications to define the structure and encoding of 3GPP interface message between different nodes in wireless communication systems. ASN. 1 provides a standardized way to describe the syntax and encoding of messages of XNAP, X2AP, NGAP, F1AP, and E1AP.

[0027] The present subject matter will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present subject matter, and which show, by way of illustration, specific examples. Please note that the present subject matter may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the examples to be set forth below.

[0028] FIG. 1 shows a diagram of an example wireless communication system 100 including a plurality of communication nodes (or just nodes) that are configured to wirelessly communicate with each other. In general, the communication nodes include at least one user device 102 and at least one wireless access node 104. The example wireless communication system 100 in FIG. 1 is shown as including two user devices 102, including a first user device 102 (1) and a second user device 102 (2) , and one wireless access nodes 104. However, various other examples of the wireless communication system 100 that include any of various combinations of one or more user devices 102 and / or one or more wireless access nodes 104 may be possible.

[0029] In general, a user device as described herein, such as the user device 102, may include a single electronic device or apparatus, or multiple (e.g., a network of) electronic devices or apparatuses, capable of communicating wirelessly over a network. A user device may comprise or otherwise be referred to as a user  terminal, a user terminal device, or a user equipment (UE) . Additionally, a user device may be or include, but not limited to, a mobile device (such as a mobile phone, a smart phone, a smart watch, a tablet, a laptop computer, vehicle or other vessel (human, motor, or engine-powered, such as an automobile, a plane, a train, a ship, or a bicycle as non-limiting examples) or a fixed or stationary device, (such as a desktop computer or other computing device that is not ordinarily moved for long periods of time, such as appliances, other relatively heavy devices including Internet of things (IoT) , or computing devices used in commercial or industrial environments, as non-limiting examples) . In various examples, a user device 102 may include transceiver circuitry 106 coupled to an antenna 108 to effect wireless communication with the wireless access node 104. The transceiver circuitry 106 may also be coupled to a processor 110, which may also be coupled to a memory 112 or other storage device. The memory 112 may store therein instructions or code that, when read and executed by the processor 110, cause the processor 110 to implement various ones of the methods described herein.

[0030] Additionally, in general, a wireless access node as described herein, such as the wireless access node 104, may include a single electronic device or apparatus, or multiple (e.g., a network of) electronic devices or apparatuses, and may comprise one or more base stations or other wireless network access points capable of communicating wirelessly over a network with one or more user devices and / or with one or more other wireless access nodes 104. For example, the wireless access node 104 may comprise a 4G LTE base station, a 5G NR base station, a 5G central-unit base station, a 5G distributed-unit base station, a next generation Node B (gNB) , an enhanced Node B (eNB) , or other similar or next-generation (e.g., 6G) base stations, in various examples. A wireless access node 104 may include transceiver circuitry 114 coupled to an antenna 116, which may include an antenna tower 118 in various approaches, to effect wireless communication with the user device 102 or another wireless access node 104. The transceiver circuitry 114 may also be coupled to one or more processors 120, which may also be coupled to a memory 122 or other storage device. The memory 122 may store therein instructions or code that, when read and executed by the processor 120, cause the processor 120 to implement one or more of the methods described herein.

[0031] In various examples, two communication nodes in the wireless system 100-such as a user device 102 and a wireless access node 104, two user devices 102 without a wireless access node 104, or two wireless access nodes 104 without a user device 102-may be configured to wirelessly communicate with each other in or over a mobile network and / or a wireless access network according to one or more standards and / or specifications. In general, the standards and / or specifications may define the rules or procedures under which the communication nodes can wirelessly communicate, which, in various examples, may include those for communicating in millimeter (mm) -Wave bands, and / or with multi-antenna schemes and beamforming functions.  In addition, or alternatively, the standards and / or specifications are those that define a radio access technology and / or a cellular technology, such as Fourth Generation (4G) Long Term Evolution (LTE) , Fifth Generation (5G) New Radio (NR) , as non-limiting examples.

[0032] Additionally, in the wireless system 100, the communication nodes are configured to wirelessly communicate signals between each other. In general, a communication in the wireless system 100 between two communication nodes can be or include a transmission or a reception, and is generally both simultaneously, depending on the perspective of a particular node in the communication. For example, for a given communication between a first node and a second node where the first node is transmitting a signal to the second node and the second node is receiving the signal from the first node, the first node may be referred to as a source or transmitting node or device, the second node may be referred to as a destination or receiving node or device, and the communication may be considered a transmission for the first node and a reception for the second node. Of course, since communication nodes in a wireless system 100 can both send and receive signals, a single communication node may be both a transmitting / source node and a receiving / destination node simultaneously or switch between being a source / transmitting node and a destination / receiving node.

[0033] Also, particular signals may be characterized or defined as either an uplink (UL) signal, a downlink (DL) signal, or a sidelink (SL) signal. An uplink signal is a signal transmitted from a user device 102 to a wireless access node 104. A downlink signal is a signal transmitted from a wireless access node 104 to a user device 102. A sidelink signal is a signal transmitted from a one user device 102 to another user device 102, or a signal transmitted from one wireless access node 104 to another wireless access node 104. Also, for sidelink transmissions, a first / source user device 102 directly transmits a sidelink signal to a second / destination user device 102 without any forwarding of the sidelink signal to a wireless access node 104.

[0034] Additionally, signals communicated between communication nodes in the system 100 may be characterized or defined as a data signal or a control signal. In general, a data signal is a signal that includes or carries data, such multimedia data (e.g., voice and / or image data) , and a control signal is a signal that carries control information that configures the communication nodes in certain ways to communicate with each other, or otherwise controls how the communication nodes communicate data signals with each other. Also, certain signals may be defined or characterized by combinations of data / control and uplink / downlink / sidelink, including uplink control signals, uplink data signals, downlink control signals, downlink data signals, sidelink control signals, and sidelink data signals.

[0035] For at least some specifications, such as 5G NR, data and control signals are transmitted and / or carried on physical channels. Generally, a physical channel corresponds to a set of time-frequency  resources used for transmission of a signal. Different types of physical channels may be used to transmit different types of signals. For example, physical data channels (or just data channels) are used to transmit data signals, and physical control channels (or just control channels) are used to transmit control signals. Example types of physical data channels include, but are not limited to, a physical downlink shared channel (PDSCH) used to communicate downlink data signals, a physical uplink shared channel (PUSCH) used to communicate uplink data signals, and a physical sidelink shared channel (PSSCH) used to communicate sidelink data signals. In addition, example types of physical control channels include, but are not limited to, a physical downlink control channel (PDCCH) used to communicate downlink control signals, a physical uplink control channel (PUCCH) used to communicate uplink control signals, and a physical sidelink control channel (PSCCH) used to communicate sidelink control signals. As used herein for simplicity, unless specified otherwise, a particular type of physical channel is also used to refer to a signal that is transmitted on that particular type of physical channel, and / or a transmission on that particular type of transmission. As an example illustration, a PDSCH refers to the physical downlink shared channel itself, a downlink data signal transmitted on the PDSCH, or a downlink data transmission. Accordingly, a communication node transmitting or receiving a PDSCH means that the communication node is transmitting or receiving a signal on a PDSCH.

[0036] Additionally, for at least some specifications, such as 5G NR, and / or for at least some types of control signals, a control signal that a communication node transmits may include control information comprising the information necessary to enable transmission of one or more data signals between communication nodes, and / or to schedule one or more data channels (or one or more transmissions on data channels) . For example, such control information may include the information necessary for proper reception, decoding, and demodulation of a data signals received on physical data channels during a data transmission, and / or for uplink scheduling grants that inform the user device about the resources and transport format to use for uplink data transmissions. In some examples, the control information includes downlink control information (DCI) that is transmitted in the downlink direction from a wireless access node 104 to a user device 102. In other examples, the control information includes uplink control information (UCI) that is transmitted in the uplink direction from a user device 102 to a wireless access node 104, or sidelink control information (SCI) that is transmitted in the sidelink direction from one user device 102 (1) to another user device 102 (2) .

[0037] Additionally, in the wireless communication system 100, a slot format for a plurality of slots or frames may be configured by the wireless access node 104 or specified by a protocol. In some examples, a slot may be indicated or specified as a downlink slot, a flexible slot, or an uplink slot. Also, an orthogonal frequency divisional multiplexing (OFDM) symbol may be indicated or specified as a downlink symbol, a  flexible symbol, or an uplink symbol, in various examples.

[0038] FIG. 2 shows an example of base station 200. The example base station 200 may include radio transmitting / receiving (Tx / Rx) circuitry 208 to transmit / receive communication with UEs and / or other base stations. The base station 200 may also include network interface circuitry 209 to communicate the base station with other base stations and / or a core network, e.g., optical or wireline interconnects, Ethernet, and / or other data transmission mediums / protocols. The base station 200 may optionally include an input / output (I / O) interface 206 to communicate with an operator or the like.

[0039] The base station 200 may also include system circuitry 204. System circuitry 204 may include processor (s) 221 and / or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 124 to perform the functions of the base station. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and / or other parameters.

[0040] As used herein, the term “network, ” referenced using reference numeral 200, interchangeably corresponds to a gNB in NR, an eNB in LTE, a base station, a core network, or a radio access node of a radio network.

[0041] FIG. 3 shows an example of an electronic device to implement a terminal device 300 (for example, user equipment (UE) ) . The UE 300 may be a mobile device, for example, a smart phone or a mobile communication module disposed in a vehicle. The UE 300 may include communication interfaces 302, a system circuitry 304, an input / output interfaces (I / O) 306, a display circuitry 308, and a storage 309. The display circuitry may include a user interface 310. The system circuitry 304 may include any combination of hardware, software, firmware, or other logic / circuitry. The system circuitry 304 may be implemented, for example, with one or more systems on a chip (SoC) , application specific integrated circuits (ASIC) , discrete analog and digital circuits, and other circuitry. The system circuitry 304 may be a part of the implementation of any desired functionality in the UE 300. In that regard, the system circuitry 304 may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface 310. The user interface 310 and the inputs / output (I / O) interfaces 306 may include a graphical user interface, touch sensitive display, haptic feedback  or other haptic output, voice or facial recognition inputs, buttons, switches, speakers, and other user interface elements. Additional examples of the I / O interfaces 306 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input  / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors) , and other types of inputs.

[0042] Referring to FIG. 3, the communication interfaces 302 may include a Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 316 which handles transmission and reception of signals through one or more antennas 314. The communication interface 302 may include one or more transceivers. The transceivers may be wireless transceivers that include modulation  / demodulation circuitry, digital to analog converters (DACs) , shaping tables, analog to digital converters (ADCs) , filters, waveform shapers, filters, pre-amplifiers, power amplifiers and / or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium. The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM) , frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 302 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) +, 4G  / Long Term Evolution (LTE) , and 5G standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP) , GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

[0043] Referring to FIG. 3, the system circuitry 304 may include one or more processors 321 and memories 322. The memory 322 stores, for example, an operating system 324, instructions 326, and parameters 328. The processor 321 is configured to execute the instructions 326 to carry out desired functionality for the UE 300. The parameters 328 may provide and specify configuration and operating options for the instructions 326. The memory 322 may also store any BT, WiFi, 3G, 4G, 5G or other data that the UE 300 will send, or has received, through the communication interfaces 302. In various implementations, a system power for the UE 300 may be supplied by a power storage device, such as a battery or a transformer.

[0044] Interface Setup Between SCP and the Node Not Supporting SBI

[0045] FIG. 4 shows an example technique to establish a connection over SCTP, referred to herein as an S interface between a first communication node 405 (e.g., gNB, gNB-CU, gNB-CU-UP, gNB-CU-CP, gNB-DU etc. ) not supporting SBI and an SCP node 410, which may be an Enhanced SCP. Once the S interface is  established, the SCP 410 may receive a 3GPP SCTP message of different interface (e.g., XnAP, NGAP, X2AP, F1AP, E1AP message, etc. ) from the first communication node 405 over the S interface and route this message to another node over SBI, or it can route a 3GPP SCTP message from another node to the communication node 405 over the S interface.

[0046] In a first step the first communication node 405 (e.g., gNB, gNB-CU, gNB-CU-UP, gNB-CU-CP, gNB-DU etc) does not support SBI. The first communication node 405 may provide multiple services for one or more other nodes (or other NFs) . In S401, the operations and management (OAM) may configure at least one available SCP (or SBI proxy) at the first communication node 405; e.g, the IP address of at least one available SCP is configured.

[0047] In S402, the first communication node 405 may send an S interface setup request (i.e., a message sent over SCTP) to an available SCP 410 requesting the establishment of an SCTP connection (i.e., the S interface) . This connection may be used to exchange application-level configuration data with another NF (or node) that supports SBI. The S interface setup request sent in S402 may optionally include one or more of the following: a list of supported 3GPP interface types to indicate which type of 3GPP interface message is supported to be delivered over the S interface; (Note: such interface type may be indicated in one of two ways: (1) It may be indicated by the following ENUMERATED types (for example, XnAP, NGAP, X2AP, F1AP, E1AP, etc. ) , or (2) by the 3GPP interface TS name (for example, TS38.423, TS38.413, TS36.423, TS38.473, TS37.483, etc. ) .

[0048] For each supported interface type included in the S interface setup request sent in S402, the request may optionally also include a list of version number (s) to indicate the supported version of such type of 3GPP interface message. For example, if the XnAP interface type is indicated to be in the S interface setup request, this would mean that the 3GPP defined XnAP message is allowed to be delivered over the S interface. Additionally, if the list of supported 3GPP interface types is not included in the S interface setup request, this would imply that no interface type restrictions exist on the S interface.

[0049] In S403, upon receiving the S interface setup request, the SCP 410 may allocate the SCTP resource for the S interface, and send an S interface setup response to the first communication node 405 to inform the first communication node 405 that the S interface is successfully established.

[0050] NF Registration Procedure of Node Not Supporting SBI

[0051] FIG. 5 shows an example technique 500 to enable a first communication node 405 not supporting SBI to send an NF registration request over the S interface, to register its NF in the NRF 505 via the SCP 410. The procedure where a node supporting SBI may register its NF service in the NRF is already specified  in the 3GPP specification, such as in TS23.501, TS23.502. Therefore, an illustration and accompanying description is omitted from this example.

[0052] In S501, the first communication node 405 may not support SBI. The first communication node 405 may provide multiple services for one or more other nodes (or other NFs) . The S interface may be established between an SCP 410 and the first communication node 405. The first communication node 405 may send an NF register request (SCTP message) to an SCP 410 over the established S interface to register the NF provided by the first communication node 405 in the NRF 505. The following may be included within the NF register request: the NF profile parameters of a node (e.g., the first communication node 405) ; wherein an indication may be included in the NF profile parameters to indicate whether the node associated with the NF profile supports SBI or not. Details about other NF profile parameters can be found in the 3GPP TS23.501, TS23.502 specifications, for example, such as NF type, NF instance ID, IP address of NF, Names of supported services (if applicable) and PLMN ID, Network Slice related Identifier (s) , and Location information for the NF instance.

[0053] In S502, upon receiving the NF register request over the S interface in S501, the SCP 410 may send an HTTP request (over SBI) , i.e. a Nnrf_NFManagement_NFRegister message, to the NRF 505, which may include the received NF profile parameters from the first communication node 405. An may be included within the NF profile parameters to indicate whether the node associated with the NF profile supports SBI or not. Step S502 registers the NF (provided by the first communication node 405) in the NRF 505. Note that the Nnrf_NFManagement_NFRegister message is a defined SBI API message based on HTTP provided by NRF; see 3GPP specification TS23.502.

[0054] In S503, upon receiving the HTTP request of S502, the NRF 505 may store the received the NF profile parameters and register the corresponding customer NF provided by the first communication node 405. In S504, the NRF 505 may send an HTTP response to the SCP 410 to inform the SCP 410 that the NF registering is successful.

[0055] In S505, upon receiving the HTTP response for NF registering in S504, the SCP 410 may send an NF register response to the first communication node 405 to inform the first communication node 405 that the corresponding customer NF provided by the first communication node 405 is successfully registered in the NRF 505.

[0056] NF Discovery Procedure

[0057] FIG. 6 shows an example technique 600 of how a communication node 405 that does not  support SBI discovers a set of NFs provided by one or more other nodes, regardless of whether these nodes supports SBI and how a communication node 605 that does support SBI discovers a set of NFs provided by one or more other nodes, again regardless of whether the other node (s) support SBI.

[0058] It should be understood that, in the context of FIG. 6, steps S601-S604 and S605-S606 may not necessarily have a sequential relationship. The steps are presented in this order to facilitate the following description.

[0059] Steps S601-S604 illustrate how a communication node 405 that does not support SBI may discover a set of NFs provided by one or more other nodes.

[0060] In S601, the first communication node 405 may not support SBI. The S interface may be established between an SCP 410 and the first communication node 405. The first communication node 405 may an NF discovery request (SCTP message) to the SCP 410 over the established S interface to discover a set of NFs with a specific service or a target NF type in the NRF 505. The NF discovery request may include discovering parameters. Details of the NF discovering parameters may be found in the 3GPP TS23.501, TS23.502 specification.

[0061] In S602, upon receiving the NF discovery request over S interface in S601, the SCP 410 may send an HTTP request, i.e. Nnrf_NFDiscovery_Request message to the NRF 505 and may include the received discovering parameters from S601. Note that the Nnrf_NFDiscovery message is a defined SBI API message based on HTTP provided by NRF; see 3GPP specification TS23.502.

[0062] In S603, upon receiving the Nnrf_NFDiscovery_Request message in S602, the NRF 505 may respond with an HTTP response to the SCP 410. The HTTP response may include list of discovered NFs. For each NF, an indication may be included to specify whether the node associated with the NF supports SBI or not.

[0063] In S604, after receiving the HTTP response for NF discovery in S603, the SCP 410 may send an NF discovery response (SCTP message) to the first communication node 405 over the established S interface. The NF discovery response may include a list of discovered NFs. Fro each NF, an indication may be included to specify whether the NF (or the node providing the NF) supports SBI or not. Thus, the first communication node 405 may be made aware of whether the target node associated with the specific discovered NF supports SBI or not. For those nodes that do not support SBI, the first communication node 405 may communicate directly with the nodes that do not support SBI via the 3GPP SCTP Interface, rather than via the SCP 410.

[0064] Steps S605 and S606 demonstrate how a node that does support SBI may discover a set of  NFs provided by other nodes.

[0065] In S605, a second communication node 605 does support SBI. The second communication node 605 may send an HTTP request, i.e., Nnrf_NFDiscovery message, to the NRF 505 and may include the discovering parameters. Note that the Nnrf_NFDiscovery message is a defined SBI API message based on HTTP provided by the NRF 505; see 3GPP specification TS23.502.

[0066] In S606, upon receiving the Nnrf_NFDiscovery message in S605, the NRF 505 may respond with an HTTP response to the second communication node 605. The HTTP response may include a list of discovered NFs. For each NF, an indication may be included to specify whether the NF (or the node providing the NF) supports SBI or not.

[0067] Communication Between a Node Supporting SBI and a Node Not Supporting SBI

[0068] FIG. 7 shows an example technique 700 to facilitate communication between a communication node 605 that supports SBI and another communication node 405 that does not. An enhanced SCP 410 may receive an SCTP (or SBI) message from a node. This message may then be converted by the SCP 410 into an SBI (or SCTP) message that the receiving node can receive via the SBI (or SCTP) interface, and the SCP 410 may subsequently send the SBI (or SCTP) message to the receiving node over the SBI (or SCTP) interface. In this way, the communication node not supporting SBI 405 may provide services to other NFs only supporting SBI, or access services provided by other NFs only supporting SBI.

[0069] The first communication node 405 may not support SBI. The S interface may be established between an SCP 410 and the first communication node 405. The first communication node 405 may provide services via the SCP 410. The communication node 2 605 does support SBI, and may provide services. As shown in S701, both the first and second communication nodes 405, 605 may have registered their respective NFs in the NRF and discovered NFs provided by the first and second communication nodes 405, 605, as well as other nodes.

[0070] In S702, if the first communication node 405 needs to provide services to the second communication node 605, or access services provided by the second communication node 605, then the first communication node 405 may send an SCTP message delivery request (SCTP message) to the SCP 410 over the established S interface to request to deliver the 3GPP message to the target node (e.g., 605) . The SCTP message delivery request may include at least one of the following: (1) a 3GPP message container, which is an OCTET STRING encoded by ASN. 1 of the corresponding 3GPP message; (2) a 3GPP interface type, which may be indicated by a value of ENUMERATED (XnAP, NGAP, X2AP, F1AP, E1AP, ... ) , or by the 3GPP interface  specification TS name, e.g., TS38.423, TS38.413, TS36.423, TS38.473, TS37.483, etc; (3) target NF information, including at least one of the following: the NF instance ID, the IP address of the NF, the NF location, the PLMN ID of the NF, the TAI of the NF, and / or the SNPN ID of the NF.

[0071] In S703, upon receiving the SCTP message delivery request over the S interface in S702, the SCP 410 may find the target node (e.g., second communication node 605) based on the target NF information send an HTTP message to the target node (e.g., second communication node 605) including at least one of the following in the message: (1) a 3GPP message container, which is an OCTET STRING encoded by ASN. 1 of the message; (2) a 3GPP interface type, which may be indicated by a value of ENUMERATED (XnAP, NGAP, X2AP, F1AP, E1AP, ... ) , or by the 3GPP interface specification TS name, e.g., TS38.423, TS38.413, TS36.423, TS38.473, TS37.483, etc.

[0072] In S704, upon receiving the HTTP message from the SCP 410 in S703, the second communication node 605 may decode the received 3GPP message container based on the indicated interface type. The second communication node 605 may then act in accordance with the behaviors specified by the 3GPP specification for receiving such a 3GPP message. If necessary, the second communication node 605 may construct a 3GPP message container for the response.

[0073] In S705, the second communication node 605 may send an HTTP delivery request (HTTP message) to the SCP 410 to request to deliver the 3GPP message container to the target node (e.g., first communication node 405) . The HTTP delivery request may include at least one of the following: (1) a 3GPP message container, which is a OCTET STRING encoded by ASN. 1 of the message; (2) a 3GPP interface type, the type could be indicated by a value of ENUMERATED (XnAP, NGAP, X2AP, F1AP, E1AP, ... ) , or by the 3GPP interface specification TS name, e.g., TS38.423, TS38.413, TS36.423, TS38.473, TS37.483, etc; (3) target NF information, including at least one of the following: the NF instance ID, the IP address of the NF, the NF location, the PLMN of the NF, the TAI of the NF, and / or the SNPN of the NF.

[0074] In S706, upon receiving the HTTP delivery request (HTTP message) in S705, the SCP 410 may find the target node (e.g., first communication node 405) based on the target NF information, and the SCP 410 may send an SCTP response to the target node. The SCTP response may include at least one of the following: (1) a 3GPP message container, which is a OCTET STRING encoded by ASN. 1 of the message; (2) a 3GPP interface type, the type could be indicated by a value of ENUMERATED (XnAP, NGAP, X2AP, F1AP, E1AP, ... ) , or by the 3GPP interface specification TS name, e.g., TS38.423, TS38.413, TS36.423, TS38.473, TS37.483, etc.

[0075] In S707, upon receiving the SCTP response from the SCP 410 in S706, the first  communication node 405 may decode the received 3GPP message container (i.e., SCTP response) based on the indicated interface type. The first communication node 405 may then act in accordance with the behaviors specified by the 3GPP specification for receiving such a 3GPP message.

[0076] NF Services Update

[0077] FIG. 8 shows an example technique 800 to enable a communication node not supporting SBI 405 to send an NF update request over the S interface to update its NF registered in the NRF 505 via the SCP 410. The procedure of a node supporting SBI updates to its NF service in the NRF 505 is already specified in the 3GPP specification, such as in TS23.501, TS23.502. Therefore, an illustration and accompanying description is omitted from this example.

[0078] The first communication node 405 may not support SBI. The first communication node 405 may provide multiple services for other nodes (or other NFs) . The S interface may be established between an SCP 410 and the first communication node 405.

[0079] In S801, the first communication node 405 may send an NF update request (SCTP message) to the SCP 410 over the established S interface to update the NF provided by the first communication node in the NRF 505. The NF update request may include the following: (1) the updated NF profile parameters of the node not supporting SBI (i.e., first communication node 405) . an indication as to whether the NF supports SBI or not may be contained in the NF profile parameters. The detail other parameters of the NF profile can be found in the 3GPP TS23.501 and TS23.502 specifications, for example, the NF type, NF instance ID, IP address of NF, Names of supported services (if applicable) , and PLMN ID, Network Slice related Identifier (s) , and Location information for the NF instance.

[0080] In S802, upon receiving the NF update request in S802, the SCP 410 may send an HTTP request, i.e., Nnrf_NFManagement_NFUpdate message to the NRF 505, including the NF profile parameters received in the NF update request. An indication may be included in the NF profile parameters to indicate whether the NF supports SBI or not. The Nnrf_NFManagement_NFUpdate message is a defined SBI API message based on HTTP provided by NRF 505; seen 3GPP specification TS23.502.

[0081] In S803, upon receiving the Nnrf_NFManagement_NFUpdate message in S802, the NRF 505 may store and update the NF profile parameters provided by the first communication node 405 in the NRF 505. In S804, the NRF 505 may send an HTTP response to the SCP 410 to inform the SCP 410 that the NF updating is successful.

[0082] In S805, upon receiving the HTTP response for NF updating in S804, the SCP 410 may send  an NF update response (SCTP message) to the first communication node 405 to inform the first communication node 405 that the corresponding customer NF provided by the first communication node 405 has been successfully updated in the NRF 505.

[0083] NF Service Deregistering

[0084] FIG. 9 shows an example technique 900 to enable a communication node not supporting SBI 405 to deregister its NF registered in the NRF 505 via the SCP 410. The procedure of a node supporting SBI deregistering its NF service in the NRF 505 is already specified in the 3GPP specification, such as in TS23.501, TS23.502. Therefore, an illustration and accompanying description is omitted from this example.

[0085] In S901, the first communication node 405 may not support SBI. The S interface may be established between the SCP 410 and the first communication node 405. The first communication node 405 may have registered its NF services in the NRF 505 via the SCP 410.

[0086] In S902, the first communication node 405 may send an S interface removal request (SCTP message) to the SCP 410 over the established S interface to remove the established S interface and deregister its NF services in the NRF 505. The S interface removal request may include an NF Instance ID to indicate the first communication node’s 405 NF instance.

[0087] In S903, upon receiving the S interface removal request over the S interface in S902, the SCP 410 may send an HTTP request to deregister the NF provided by the first communication node 405 in the NRF 505. That is, a Nnrf_NFManagement_NFDeregister message may be sent to the NRF 505 and include the received NF Instance ID in the HTTP request. The Nnrf_NFManagement_NFDeregister message is a defined SBI API message based on HTTP provided by NRF 505; see 3GPP specification TS23.502.

[0088] In S904, upon receiving the Nnrf_NFManagement_NFDeregister message (HTTP request) in S903 and based on the received NF Instance ID, the NRF 505 may remove the corresponding NF profile parameters provided by the first communication node 405 in the NRF 505, and deregister the NF (provided by the first communication node 405) in the NRF 505. In S905, the NRF 505 may send an HTTP response message in S905 to the SCP 410 to inform the SCP 410 that the NF deregistering is successful.

[0089] In S906, upon receiving the HTTP response message for NF deregistering in S905, the SCP 410 may send an S interface removal response (SCTP message) to the first communication node 405 to inform the first communication node 405 that the corresponding customer NF provided by the first communication node 405 is successfully deregistered in the NRF 505. The S interface may be removed, and then the SCP 410 may release the SCTP resource for the S interface.

[0090] The description and accompanying drawings above provide specific examples and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any examples set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, implementations may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the methods described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0091] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one example / implementation” as used herein does not necessarily refer to the same sample and the phrase “in another example / implementation” as used herein does not necessarily refer to a different example. It is intended, for example, that claimed subject matter includes combinations of examples in whole or in part.

[0092] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures, or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0093] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an example is included in at least one example of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same example.

[0094] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more examples. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular example. In other instances, additional features and advantages may be recognized in certain examples that may not be present in all examples of the present solution.

[0095] The subject matter of the disclosure may also relate to or include, among others, the following aspects:

[0096] A first aspect includes a method for communicating between a first node and a second node via a service communication proxy (SCP) , comprising: establishing a stream control transmission protocol (SCTP) interface between the first node and the SCP; communicating between the first node and the SCP via the established SCTP interface; and communicating between the second node and the SCP via a service-based interface (SBI) , wherein the first node does not support the SBI, and the second node supports the SBI.

[0097] A second aspect includes the method of aspect 1, wherein the establishing comprises: receiving, by the SCP, a request from the first node to establish the SCTP interface, wherein the request includes: a list of supported 3GPP interface types to indicate a type of 3GPP interface message that is supported and deliverable over the SCTP interface; and for each supported 3GPP interface type, optional with an optional list of version numbers to indicate one or more supported versions of the type of 3GPP interface message.

[0098] A third aspect includes the method of any prior aspect, wherein the supported 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface technical specification (TS) name.

[0099] A fourth aspect includes the method of any prior aspect, further comprising: assisting the first node to register its network function (NF) via the SCP, comprising: receiving, by the SCP, an NF register request from the first node via the SCTP interface, wherein the NF register request comprises: NF profile parameters of the first node, and an indication of whether the first node supports the SBI.

[0100] A fifth aspect includes the method of any prior aspect, further comprising: sending, by the SCP, a hypertext transfer protocol (HTTP) request to a network repository function (NRF) via the SBI to request registration of the NF of the first node, wherein the HTTP request comprises: the NF profile parameters of the first node, and the indication of whether the first node supports the SBI.

[0101] A sixth aspect includes the method of any prior aspect, further comprising: assisting the first node to discover other NFs via the SCP, comprising: receiving, by the SCP, an NF discovery request from the first node via the SCTP interface; and in response: sending, by the SCP, an HTTP request for NF discovery to an  NRF via the SBI.

[0102] A seventh aspect includes the method of any prior aspect, further comprising: assisting the first node to discover other NFs via the SCP, comprising: receiving, by the SCP, an HTTP response from an NRF, wherein the HTTP response comprises: a list of discovered NFs, and for each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.

[0103] An eighth aspect includes the method of any prior aspect, further comprising: subsequently, sending, by the SCP, an NF discovery response via the SCTP interface to first node, wherein the NF discovery response comprises: the list of discovered NFs, and for each discovered NF, the indication of whether a node associated with the discovered NF supports SBI.

[0104] A ninth aspect includes the method of any prior aspect, further comprising: assisting the second node to discover other NFs without SBI support via the SCP, comprising: sending, by an NRF, an HTTP response to the second node, wherein the HTTP response comprises: a list of discovered NFs, and for each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.

[0105] A tenth aspect includes the method of any prior aspect, further comprising: assisting indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, the assisting comprising: receiving, by the SCP, a 3GPP message delivery request from the first node via the SCTP interface to request delivery of a 3GPP message to the second node, wherein the 3GPP message delivery request comprises: a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; a 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface TS name; and target NF information comprising at least one of: an NF instance ID, an IP address of the NF, an NF location, a PLMN ID of the NF, a TAI of the NF, and / or a SNPN ID of the NF.

[0106] An eleventh aspect includes the method of any prior aspect, further comprising: sending, by the SCP via the SBI, a HTTP message for message delivery to the second node associated with the target NF, wherein the HTTP message comprises: the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; the 3GPP interface type is indicated by: the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or the 3GPP interface TS name.

[0107] A twelfth aspect includes the method of any prior aspect, further comprising: assisting indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, and the assisting comprises: receiving, by the SCP, an HTTP request message comprising a 3GPP message delivery request from the second node via the SBI to request delivery of a 3GPP message to the first node, wherein the  HTTP request message comprises: a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; a 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface TS name; and target NF information comprising at least one of: an NF instance ID, an IP address of the NF, an NF location, a PLMN ID of the NF, a TAI of the NF, and / or a SNPN ID of the NF.

[0108] A thirteenth aspect includes the method of any prior aspect, further comprising: sending, by the SCP via the SCTP interface, an SCTP message for message delivery to the first node associated with the target NF, wherein the SCTP message comprises: the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; the 3GPP interface type is indicated by: the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or the 3GPP interface TS name.

[0109] A fourteenth aspect includes the method of any prior aspect, further comprising: assisting the first node to update its NF via the SCP, comprising: receiving, by the SCP, an NF update request from the first node via the SCTP interface, wherein the NF update request comprises: updated NF profile parameters of the first node, and an indication of whether a node associated with the updated NF profile parameters supports SBI.

[0110] A fifteenth aspect includes the method of any prior aspect, further comprising: subsequently, sending, by the SCP, an HTTP message comprising the NF update request to an NRF via the SBI to request updating the NF of the first node, wherein the HTTP message comprises: the updated NF profile parameters of the first node, and the indication of whether the node associated with the updated NF profile parameters supports SBI.

[0111] A sixteenth aspect includes the method of any prior aspect, further comprising: assisting the first node to deregister its NF via the SCP, comprising: receiving, by the SCP, an SCTP interface removal request from the first node via the SCTP interface; and subsequently, sending, by the SCP, an HTTP request to an NRF to deregister the NF of the first node.

[0112] A seventeenth aspect includes a system for wirelessly communicating between a first node and a second node via a service communication proxy (SCP) , comprising: a processor; and a memory in communication with the processor, the memory storing instructions executable by the processor to configure the system to: establish a stream control transmission protocol (SCTP) interface between the first node and the SCP; communicate between the first node and the SCP via the established SCTP interface; and communicate between the second node and the SCP via a service-based interface (SBI) , wherein the first node does not support the SBI, and the second node supports the SBI.

[0113] An eighteenth aspect includes the system of aspect 17, further configured to: receive, by the SCP, a  request from the first node to establish the SCTP interface, wherein the request includes: a list of supported 3GPP interface types to indicate a type of 3GPP interface message that is supported and deliverable over the SCTP interface; and for each supported 3GPP interface type, optional with a list of version numbers to indicate one or more supported versions of the type of 3GPP interface message.

[0114] A nineteenth aspect includes the system of aspects 17-18, wherein the supported 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface technical specification (TS) name.

[0115] A twentieth aspect includes the system of aspects 17-19, further configured to: assist the first node to register its network function (NF) via the SCP, by being further configured to: receive, by the SCP, an NF register request from the first node via the SCTP interface, wherein the NF register request comprises: NF profile parameters of the first node, and an indication of whether the first node supports the SBI.

[0116] A twenty-first aspect includes the system of aspects 17-20, further configured to: send, by the SCP, a hypertext transfer protocol (HTTP) request to a network repository function (NRF) via the SBI to request registration of the NF of the first node, wherein the HTTP request comprises: the NF profile parameters of the first node, and the indication of whether the first node supports the SBI.

[0117] A twenty-second aspect includes the system of aspects 17-21, further configured to: assist the first node to discover other NFs via the SCP, by being further configured to: receive, by the SCP, an NF discovery request from the first node via the SCTP interface; and in response: send, by the SCP, an HTTP request for NF discovery to an NRF via the SBI.

[0118] A twenty-third aspect includes the system of aspects 17-22, further configured to: assist the first node to discover other NFs via the SCP, by being further configured to: receive, by the SCP, an HTTP response from an NRF, wherein the HTTP response comprises: a list of discovered NFs, and for each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.

[0119] A twenty-fourth aspect includes the system of aspects 17-23, further configured to: subsequently, send, by the SCP, an NF discovery response via the SCTP interface to the first node, wherein the NF discovery response comprises: the list of discovered NFs, and for each discovered NF, the indication of whether a node associated with the discovered NF supports SBI.

[0120] A twenty-fifth aspect includes the system of aspects 17-24, further configured to: assist the second node to discover other NFs without SBI support via the SCP, by being further configured to: send, by an NRF, an HTTP response to the second node, wherein the HTTP response comprises: a list of discovered NFs, and for each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.

[0121] A twenty-sixth aspect includes the system of aspects 17-25, further configured to: assist indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, and the system is further configured to: receive, by the SCP, a 3GPP message delivery request from the first node via the SCTP interface to request delivery of a 3GPP message to the second node, wherein the 3GPP message delivery request comprises: a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; a 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface TS name; and target NF information comprising at least one of:an NF instance ID, an IP address of the NF, an NF location, a PLMN ID of the NF, a TAI of the NF, and / or a SNPN ID of the NF.

[0122] A twenty-seventh aspect includes the system of aspects 17-26, further configured to: send, by the SCP via the SBI, an HTTP message for message delivery to the second node associated with the target NF, wherein the HTTP message comprises: the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; the 3GPP interface type is indicated by: the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or the 3GPP interface TS name.

[0123] A twenty-eighth aspect includes the system of aspects 17-27, further configured to: assist indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, and the system is further configured to: receive, by the SCP, an HTTP request message comprising a 3GPP message delivery request from the second node via the SBI to request delivery of a 3GPP message to the first node, wherein the HTTP request message comprises: a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; a 3GPP interface type is indicated by: an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or a 3GPP interface TS name; and target NF information comprising at least one of: an NF instance ID, an IP address of the NF, an NF location, a PLMN ID of the NF, a TAI of the NF, and / or a SNPN ID of the NF.

[0124] A twenty-ninth aspect includes the system of aspects 17-28, further configured to: send, by the SCP via the SCTP interface, a SCTP message for message delivery to the first node associated with the target NF, wherein the SCTP message comprises: the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message; the 3GPP interface type is indicated by: the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; or the 3GPP interface TS name.

[0125] A thirtieth aspect includes the system of aspects 17-29, further configured to: assist the first node to update its NF via the SCP, by being further configured to: receive, by the SCP, an NF update request from the first node via the SCTP interface, wherein the NF update request comprises: updated NF profile parameters of  the first node, and an indication of whether a node associated with the updated NF profile parameters supports SBI.

[0126] A thirty-first aspect includes the system of aspects 17-30, further configured to: subsequently, send, by the SCP, an HTTP message comprising the NF update request to an NRF via the SBI to request updating the NF of the first node, wherein the HTTP message comprises: the updated NF profile parameters of the first node, and the indication of whether the node associated with the updated NF profile parameters supports SBI.

[0127] A thirty-second aspect includes the system of aspects 17-31, further configured to: assist the first node to deregister its NF via the SCP, by being further configured to: receive, by the SCP, an SCTP interface removal request from the first node via the SCTP interface; and subsequently, send, by the SCP, an HTTP request to an NRF to deregister the NF of the first node.

[0128] A thirty-third aspect includes a non-transitory computer-readable medium comprising instructions operable, when executed by one or more processors, to communicate between a first node and a second node via a service communication proxy (SCP) by configuring the one or more processors to: establish a stream control transmission protocol (SCTP) interface between the first node and the SCP; communicate between the first node and the SCP via the established SCTP interface; and communicate between the second node and the SCP via a service-based interface (SBI) , wherein the first node does not support the SBI, and the second node supports the SBI.

Claims

1.A method for communicating between a first node and a second node via a service communication proxy (SCP) , comprising:establishing a stream control transmission protocol (SCTP) interface between the first node and the SCP;communicating between the first node and the SCP via the established SCTP interface; andcommunicating between the second node and the SCP via a service-based interface (SBI) , whereinthe first node does not support the SBI, andthe second node supports the SBI.2.The method of claim 1, wherein the establishing comprises:receiving, by the SCP, a request from the first node to establish the SCTP interface, wherein the request includes:a list of supported 3GPP interface types to indicate a type of 3GPP interface message that is supported and deliverable over the SCTP interface; andfor each supported 3GPP interface type, optional with an optional list of version numbers to indicate one or more supported versions of the type of 3GPP interface message.3.The method of claim 2, wherein the supported 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface technical specification (TS) name.4.The method of claim 1, further comprising:assisting the first node to register its network function (NF) via the SCP, comprising:receiving, by the SCP, an NF register request from the first node via the SCTP interface, wherein the NF register request comprises:NF profile parameters of the first node, andan indication of whether the first node supports the SBI.5.The method of claim 4, further comprising:sending, by the SCP, a hypertext transfer protocol (HTTP) request to a network repository function (NRF) via the SBI to request registration of the NF of the first node, wherein the HTTP request comprises:the NF profile parameters of the first node, andthe indication of whether the first node supports the SBI.6.The method of claim 1, further comprising:assisting the first node to discover other NFs via the SCP, comprising:receiving, by the SCP, an NF discovery request from the first node via the SCTP interface; and in response:sending, by the SCP, an HTTP request for NF discovery to an NRF via the SBI.7.The method of claim 1, further comprising:assisting the first node to discover other NFs via the SCP, comprising:receiving, by the SCP, an HTTP response from an NRF, wherein the HTTP response comprises:a list of discovered NFs, andfor each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.8.The method of claim 7, further comprising:subsequently, sending, by the SCP, an NF discovery response via the SCTP interface to first node, wherein the NF discovery response comprises:the list of discovered NFs, andfor each discovered NF, the indication of whether a node associated with the discovered NF supports SBI.9.The method of claim 1, further comprising:assisting the second node to discover other NFs without SBI support via the SCP, comprising:sending, by an NRF, an HTTP response to the second node, wherein the HTTP response comprises:a list of discovered NFs, andfor each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.10.The method of claim 1, further comprising:assisting indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, the assisting comprising:receiving, by the SCP, a 3GPP message delivery request from the first node via the SCTP interface to request delivery of a 3GPP message to the second node, wherein the 3GPP message delivery request comprises:a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;a 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface TS name; andtarget NF information comprising at least one of:an NF instance ID,an IP address of the NF,an NF location,a PLMN ID of the NF,a TAI of the NF, and / ora SNPN ID of the NF.11.The method of claim 10, further comprising:sending, by the SCP via the SBI, a HTTP message for message delivery to the second node associated with the target NF, wherein the HTTP message comprises:the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;the 3GPP interface type is indicated by:the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; orthe 3GPP interface TS name.12.The method of claim 1, further comprising:assisting indirection communication between the first node and the second node via the SCP, wherein the first node has an NF, and the assisting comprises:receiving, by the SCP, an HTTP request message comprising a 3GPP message delivery request from the second node via the SBI to request delivery of a 3GPP message to the first node, wherein the HTTP request message comprises:a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;a 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface TS name; andtarget NF information comprising at least one of:an NF instance ID,an IP address of the NF,an NF location,a PLMN ID of the NF,a TAI of the NF, and / ora SNPN ID of the NF.13.The method of claim 12, further comprising:sending, by the SCP via the SCTP interface, an SCTP message for message delivery to the first node associated with the target NF, wherein the SCTP message comprises:the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;the 3GPP interface type is indicated by:the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; orthe 3GPP interface TS name.14.The method of claim 1, further comprising:assisting the first node to update its NF via the SCP, comprising:receiving, by the SCP, an NF update request from the first node via the SCTP interface, wherein the NF update request comprises:updated NF profile parameters of the first node, andan indication of whether a node associated with the updated NF profile parameters supports SBI.15.The method of claim 14, further comprising:subsequently, sending, by the SCP, an HTTP message comprising the NF update request to an NRF via the SBI to request updating the NF of the first node, wherein the HTTP message comprises:the updated NF profile parameters of the first node, andthe indication of whether the node associated with the updated NF profile parameters supports SBI.16.The method of claim 1, further comprising:assisting the first node to deregister its NF via the SCP, comprising:receiving, by the SCP, an SCTP interface removal request from the first node via the SCTP interface; andsubsequently, sending, by the SCP, an HTTP request to an NRF to deregister the NF of the first node.17.A system for wirelessly communicating between a first node and a second node via a service communication proxy (SCP) , comprising:a processor; anda memory in communication with the processor, the memory storing instructions executable by the processor to configure the system to:establish a stream control transmission protocol (SCTP) interface between the first node and the SCP;communicate between the first node and the SCP via the established SCTP interface; andcommunicate between the second node and the SCP via a service-based interface (SBI) , whereinthe first node does not support the SBI, andthe second node supports the SBI.18.The system of claim 17, wherein the system is further configured to:receive, by the SCP, a request from the first node to establish the SCTP interface, wherein the request includes:a list of supported 3GPP interface types to indicate a type of 3GPP interface message that is supported and deliverable over the SCTP interface; andfor each supported 3GPP interface type, optional with a list of version numbers to indicate one or more supported versions of the type of 3GPP interface message.19.The system of claim 18, wherein the supported 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface technical specification (TS) name.20.The system of claim 17, further configured to:assist the first node to register its network function (NF) via the SCP, by being further configured to:receive, by the SCP, an NF register request from the first node via the SCTP interface, wherein the NF register request comprises:NF profile parameters of the first node, andan indication of whether the first node supports the SBI.21.The system of claim 20, further configured to:send, by the SCP, a hypertext transfer protocol (HTTP) request to a network repository function (NRF) via the SBI to request registration of the NF of the first node, wherein the HTTP request comprises:the NF profile parameters of the first node, andthe indication of whether the first node supports the SBI.22.The system of claim 17, further configured to:assist the first node to discover other NFs via the SCP, by being further configured to:receive, by the SCP, an NF discovery request from the first node via the SCTP interface; and in response:send, by the SCP, an HTTP request for NF discovery to an NRF via the SBI.23.The system of claim 17, further configured to:assist the first node to discover other NFs via the SCP, by being further configured to:receive, by the SCP, an HTTP response from an NRF, wherein the HTTP response comprises:a list of discovered NFs, andfor each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.24.The system of claim 23, further configured to:subsequently, send, by the SCP, an NF discovery response via the SCTP interface to the first node, wherein the NF discovery response comprises:the list of discovered NFs, andfor each discovered NF, the indication of whether a node associated with the discovered NF supports SBI.25.The system of claim 17, further configured to:assist the second node to discover other NFs without SBI support via the SCP, by being further configured to:send, by an NRF, an HTTP response to the second node, wherein the HTTP response comprises:a list of discovered NFs, andfor each discovered NF, an indication of whether a node associated with the discovered NF supports SBI.26.The system of claim 17, further configured to:assist indirection communication between the first node and the second node via the SCP, whereinthe first node has an NF, andthe system is further configured to:receive, by the SCP, a 3GPP message delivery request from the first node via the SCTP interface to request delivery of a 3GPP message to the second node, wherein the 3GPP message delivery request comprises:a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;a 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface TS name; andtarget NF information comprising at least one of:an NF instance ID,an IP address of the NF,an NF location,a PLMN ID of the NF,a TAI of the NF, and / ora SNPN ID of the NF.27.The system of claim 26, further configured to:send, by the SCP via the SBI, an HTTP message for message delivery to the second node associated with the target NF, wherein the HTTP message comprises:the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;the 3GPP interface type is indicated by:the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; orthe 3GPP interface TS name.28.The system of claim 17, further configured to:assist indirection communication between the first node and the second node via the SCP, whereinthe first node has an NF, andthe system is further configured to:receive, by the SCP, an HTTP request message comprising a 3GPP message delivery request from the second node via the SBI to request delivery of a 3GPP message to the first node, wherein the HTTP request message comprises:a 3GPP message container comprising an octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;a 3GPP interface type is indicated by:an enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; ora 3GPP interface TS name; andtarget NF information comprising at least one of:an NF instance ID,an IP address of the NF,an NF location,a PLMN ID of the NF,a TAI of the NF, and / ora SNPN ID of the NF.29.The system of claim 28, further configured to:send, by the SCP via the SCTP interface, a SCTP message for message delivery to the first node associated with the target NF, wherein the SCTP message comprises:the 3GPP message container comprising the octet string encoded by abstract syntax notation one (ASN. 1) of the 3GPP message;the 3GPP interface type is indicated by:the enumerated type of XnAP, NGAP, X2AP, F1AP, or E1AP; orthe 3GPP interface TS name.30.The system of claim 17, further configured to:assist the first node to update its NF via the SCP, by being further configured to:receive, by the SCP, an NF update request from the first node via the SCTP interface, wherein the NF update request comprises:updated NF profile parameters of the first node, andan indication of whether a node associated with the updated NF profile parameters supports SBI.31.The system of claim 30, further configured to:subsequently, send, by the SCP, an HTTP message comprising the NF update request to an NRF via the SBI to request updating the NF of the first node, wherein the HTTP message comprises:the updated NF profile parameters of the first node, andthe indication of whether the node associated with the updated NF profile parameters supports SBI.32.The system of claim 17, further configured to:assist the first node to deregister its NF via the SCP, by being further configured to:receive, by the SCP, an SCTP interface removal request from the first node via the SCTP interface; andsubsequently, send, by the SCP, an HTTP request to an NRF to deregister the NF of the first node.33.A non-transitory computer-readable medium comprising instructions operable, when executed by one or more processors, to communicate between a first node and a second node via a service communication proxy (SCP) by configuring the one or more processors to:establish a stream control transmission protocol (SCTP) interface between the first node and the SCP;communicate between the first node and the SCP via the established SCTP interface; andcommunicate between the second node and the SCP via a service-based interface (SBI) , whereinthe first node does not support the SBI, andthe second node supports the SBI.

Images