WO2020034465A1

WO2020034465A1 - Method of communication for service framework

Info

Publication number: WO2020034465A1
Application number: PCT/CN2018/115396
Authority: WO
Inventors: Jinguo Zhu; Shuang Liang
Original assignee: Zte Corporation
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2020-02-20
Also published as: CN112997455B; CN112997455A

Abstract

Methods, systems, and devices related to related to digital wireless communication, and more specifically, to techniques related to communicating between multiple service frameworks are disclosed. In one exemplary aspect, a method for wireless communication includes receiving, by a service framework (SF), a network function service (NFS) identification information to identify a NFS and a context data identifier to identify a context data. The method also includes allocating, by the SF, a SF identification information identifying the SF. The method also includes storing, by the SF, the context data identifier and the NFS identification information. The method also includes transmitting, by the SF, the SF identifier to the NFS.

Description

METHOD OF COMMUNICATION FOR SERVICE FRAMEWORK

TECHNICAL FIELD

This patent document is directed generally to wireless communications.

BACKGROUND

Mobile communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of mobile communications and advances in technology have led to greater demand for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios. Various techniques, including new ways to provide higher quality of service, are being discussed.

SUMMARY OF PARTICULAR EMBODIMENTS

This document discloses methods, systems, and devices related to digital wireless communication, and more specifically, to techniques related to reporting of user equipment (UE) capabilities when it is connected to multiple network nodes.

In one exemplary aspect, a method for wireless communication is disclosed. The method includes allocating, by a service framework (SF) , a SF identifier identifying the SF. The method also includes transmitting, by the SF, the SF identifier to the NFS.

In another exemplary aspect, a method for wireless communication is disclosed. The method includes receiving, by a network function service (NFS) , a service framework (SF) identifier identifying a SF. The method also includes transmitting, by the NFS, a NFS service profile and the SF identifier identifying the SF to a network function repository function (NRF) .

In another exemplary aspect, a wireless communications apparatus comprising a processor is disclosed. The processor is configured to implement a method described herein.

In yet another exemplary aspect, the various techniques described herein may be embodied as processor-executable code and stored on a computer-readable program medium.

The details of one or more implementations are set forth in the accompanying attachments, the drawings, and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary schematic diagram of a system architecture for Dual Connectivity (DC) .

FIG. 2 shows a communication environment.

FIG. 3 illustrates an exemplary signaling process of service registration process and a NRF registration/update process.

FIG. 4 illustrates an exemplary signaling process establishing a communication session between NFS instances and service frameworks.

FIG. 5 illustrates an exemplary signaling process for re-establishing a communication session.

FIG. 6 illustrates an exemplary signaling process for re-establishing a communication session for NFS1 to communicate with a target.

FIG. 7 shows a flow chart representation of a method for wireless communication.

FIG. 8 shows a flow chart representation of a method for wireless communication.

FIG. 9 shows an example of a wireless communication system where techniques in accordance with one or more embodiments of the present technology can be applied.

FIG. 10 is a block diagram representation of a portion of a radio station.

DETAILED DESCRIPTION

The development of the new generation of wireless communication -5G New Radio (NR) communication -is a part of a continuous mobile broadband evolution process to meet the requirements of increasing network demand. NR will provide greater throughput to allow more users connected at the same time. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios.

As NR emerges in the wireless domain, UEs will be capable of supporting both protocols at the same time. FIG. 1 shows an exemplary schematic diagram of a system architecture for Dual Connectivity (DC) . The current base station (referred to as the first network element 101) in the core network 103 may select a suitable base station for the UE 100 to function as the second network element 102. For example, the suitable based station can be selected by comparing the channel quality of the base station with a predetermined threshold. Both base stations can provide radio resources to the UE 100 for data transmission on the user plane. On the wired interface side, the first network element 101 and the core network 103 establish a control plane interface 104 for the UE 100. The second network element 102 and the core network 103 may establish a user plane interface 105 for the UE 100. An interface 106 (e.g., Xn interface) inter-connects the two network elements. On the wireless interface side, the first and the second network elements (101 and 102) may provide radio resources using the same or different Radio Access Technologies (RATs) . Each of the network element can schedule transmissions with the UE 100 independently. The network element that has a control plane connection to the core network is referred to as the master node (e.g., the first network element 101) , and the network element that has only a user plane connection with the core network is referred to as the secondary node (e.g., the second network element 102) . In some cases, the UE 100 can be connected to more than two nodes, with one node acting as the primary note and the remaining acting as the secondary nodes.

In some embodiments, a UE can support a LTE-NR dual connection (DC) . For example, one of the typical LTE-NR dual connectivity architectures can be set up as follows: the master node is an LTE RAN node (e.g., eNB) and the secondary node is an NR RAN node (e.g., gNB) . The eNB and the gNB are simultaneously connected the Evolved Packet Core (EPC) network (e.g., LTE core network) . The architecture shown in FIG. 1 can also be modified to include various master/secondary node configurations. For example, a NR RAN node can be the master node and the LTE RAN node can be the secondary node. In such case, the core network for the master NR RAN node is a Next Generation Converged Network (NG-CN) .

One or more NFS instances may be connected to a service framework. One or more service frameworks may be included within a communication environment. To communicate between NFS instances in different NFS sets, messages may be routed between multiple service frameworks throughout the communication environment.

This patent document describes techniques facilitate communication between NFS instances located within different NFS sets. A service framework may store a UE context data identifier identifying UE context data and NFS identification information indicative of the NFS. The association between the UE context data identifier identifying UE context data and NFS identification information indicative of the NFS may be referred to as a “temporary binding. ” The temporary binding may not impact the scale in/out of the service instance in one NFS set and the ongoing sessions transmitted to other network function instances. Section headings are used only for ease of understanding and do not limit the embodiments disclosed in each section only to that section. Furthermore, examples of terminology and protocols used in 5G networks is used to facilitate understanding and the disclosed techniques are applicable to other wireless systems that implement other communication protocols.

FIG. 2 shows a communication environment 200. As shown in FIG. 2, multiple network functions services (NFS) may be included within the environment 200. An NFS within the environment (e.g., NFS1 231) may be referred to as an “NFS instance. ” Each NFS instance may handle service logic and expose service to other authorized NFS instances within the environment 200.

In some embodiments, one or more NFS instances are grouped into a NFS set. For purposes of illustration, as shown in FIG. 2, NFS1 231, NFS2 232, and NFS3 233 are grouped into NFS set 1 237. Similarly, for purposes of illustration, as shown in FIG. 2, NFS4 234, NFS5 235, and NFS6 236 are grouped into NFS set 2 238. Within each NFS set (e.g., NFS set 1 237) , the capabilities of each NFS are substantially similar. In other words, each NFS instance within the NFS set (e.g., NFS1 231, NFS2 232, NFS3 233 within NFS set 1 237) may access the same data sets stored within a data storage entity (e.g., unstructured data storage function 1 (UDSF1) 239) . Accordingly, each NFS instance within a NFS set may process UE transactions, as each NFS instance may access context data (e.g., UE context data) .

As shown in FIG. 2, environment 200 may include a Network Repository Function (NRF) 241. The NRF 241 may support service discovery within the same service framework or between multiple service frameworks (SFs) . The NRF 241 may maintain a NFS profile that includes all available NFS instances and corresponding supported services and service frameworks. In some embodiments, the NRF 241 receives a NFS discovery request from a NFS (e.g., NFS1 241) . In response to this request, the NRF 241 may transmit the information of the discovered NFS instances to the NFS that transmitted the request (e.g., NFS1 231) .

The environment 200 may include one or more service frameworks. A service framework (e.g., service framework 1 242 and service framework 2 243) may perform registration and discovery functionality and communicate between NFS instances. In some embodiments, each service framework may be realized in an operator network using various mechanisms and could support various models of distribution and connectivity with the network function services.

Example Embodiment 1

FIG. 3 illustrates an exemplary signaling process 300 of service registration process and a NRF registration/update process. A NFS (e.g., NFS1 331) may be in communication with a service framework 342 and a NRF 341 via the service framework 342.

Step 301: The NFS 331 may become active for the first time. The NFS 331 as described with respect to FIG. 3 may also be referred to as a “NF service instance consumer. ”

Step 302: The NFS 331 may register with the service framework 342. The NFS 331 may initiate the registration by transmitting a service registration request to the service framework 342. The service registration request may include NFS set identification information indicative of identifying a NFS set within a communication environment. For example, the NFS set identification information may identify NFS set 1 237 as illustrated in FIG. 2. The service registration request may also include NFS identification information indicative of a NFS, such as NFS 331 in FIG. 3. The NFS identification information may be represented as ID (NSF1) . The NFS set identification information and the NFS identification information may be used by the service framework 342 for forwarding information to an identified NFS located within an identified NFS set.

Step 303: The service framework 342 may store the NFS identification information that enables the routing of information to an NFS associated with the service framework 342. In some embodiments, the service framework 342 may allocate an SF identity to uniquely identify the service framework 342 and an associated NFS set. The SF identity may be represented as ID(SF) . The SF identity may identify a service framework 342 in a communication environment comprising multiple service frameworks and NFS sets. For example, a SF identity may identify service framework 1 (or simply “SF1” ) 242 as illustrated in FIG. 2. The SF identity may be utilized in forwarding information to NFS instances associated with the identified service framework 342.

The service framework 342 may transmit a service registration response to the NFS 331 to indicate a successful registration. The service registration response may include the SF identity of the service framework 342.

Step 304: The NFS 331 may transmit a NRF registration/update request to a NRF 341. The NRF registration/update request may include information representing a request to register information associated with the NFS 331 with the NRF 341. The NRF registration/update request may include a NFS profile and the SF identity received from the service framework 342 as described in Step 303. The NFS profile may include information indicative of the NFS 331, such as available NF service instances and their supported services, for example.

In some embodiments, the NRF 341 may include the NFS profile and/or the SF identity associated with the NFS 331 prior to receipt of the NRF registration/update request. In these embodiments, the NRF registration/update request may include an updated NFS profile or an updated SF identity.

Step 305: The NRF 341 may receive the NRF registration/update request. The NRF 341 may store the NFS profile and the SF identity associated with the NFS profile. Upon receipt and/or successful storage of the NFS profile and the SF identity, the NRF 341 may transmit a NRF registration/update response to the NFS 331 to indicate that the registration was successful.

Similarly, in some embodiments, the NRF 341 may have a NFS profile and/or a SF identity stored prior to receiving the NRF registration/update request. In these embodiments, the NRF 341 may determine whether the NRF registration/update request includes an updated NFS profile and/or an updated SF identity. Based on determining that the NRF registration/update request includes an updated NFS profile and/or an updated SF identity, the NRF 341 may store the updated NFS profile and/or the updated SF identity associated with the NFS profile. The NRF 341 may transmit a NRF registration/update response to the NFS to indicate that the update to the NFS profile and/or the SF identity was successful.

Example Embodiment 2

FIG. 4 illustrates an exemplary signaling process 400 establishing a communication session between NFS instances and service frameworks. In this example embodiment, NFS1 and NFS5 may not store information relating to the peer NFS. Rather, NFS1 and NFS5 may store the target identity that uniquely identifies the target NFS set and the target SF identity. Accordingly, the scale in/out of any NFS (e.g., NFS1 431) does not impact the communication peer NFS (e.g., NFS 435) , and the service framework complexity is reduced.

Step 401: The NFS1 431 may allocate a first UE context data identity. The first UE context data identity data may also be represented as “ID (A) . ” The first UE context data identity may uniquely identify UE context data (or simply “context data” ) in the first NFS set 437. In some embodiments, when the UE context data is created by NFS1 431, NFS1 431 allocates a first UE context data identity to identify the UE context data. In other embodiments, the NFS1 431 may request UDSF1 439 to allocate the first UE context data identity to identify the UE context data.

In some embodiments, UE context data may be stored in a UDSF (e.g., USDF1 439) . If a communication session is active in NFS1 431, and NFS1 431 does not have the UE context data, but UDSF1 439 has already stored the UE context data, the NFS1 431 may retrieve the UE context data the UDSF1 439. After this step, the UE context data may include a temporary binding to NFS1 431.

Step 402: NFS1 431 may transmit a create UE binding request to service framework 1 442. The create UE binding request may include the first UE context data identity (ID (A) ) and NFS identification information indicative of NFS1 431 (ID (NFS1) ) as described herein. The create UE binding request may instruct SF1 442 to store the temporary binding of the first UE context data identity in SF1 442.

Step 403: The SF1 442 may store the temporary binding between the first UE context data identity (ID (A) ) and the NFS identification information indicative of NFS1 431 (ID (NFS1) ) .

Step 404: The SF1 442 may transmit a create UE binding acknowledgement to NFS1 431. The create UE binding acknowledgement may indicate that the temporary binding was stored at SF1 442.

Step 405: In some embodiments, NFS1 transmits an NRF discovery request to the NRF 441. The NRF discovery request may include a target NFS type, where the target NFS type is indicative of a type of NFS that would be a suitable communication peer with NFS1.

Step 406: In some embodiments, the NRF 441 may determine a target identifier based on the target NFS type received in the NRF discovery request. The target identifier may indicate a recipient service framework associated with a NFS set. For example, the target identifier may identify service framework 2 ( “SF2” ) 443 associated with NFS set 2 438. The target identifier may be represented as ID (SF2) . Upon determining a target identifier, NRF 441 may store the ID (SF2) when the NFS in NFS set 2 is registered in the NRF 441. The NRF 441 may transmit a NRF discovery response message indicating the target identifier (e.g., ID (SF2) ) .

Step 407: The NFS1 431 transmits a message to SF1 442. The message includes the target identifier ID (SF2) , which may be used by SF1 442 to forward the message to SF2 443 identified in the target identifier. The message may include the first UE context data identity ID (A) and SF1 identification information to identify SF1 442 as associated with first UE context data identity ID (A) . The service framework 1 identification information may be referred to as ID (SF1) . The first UE context data identity ID (A) and SF1 identification information may be stored in the peer NFS (e.g., NFS5 435) for use in subsequent communications.

Step 408: Service framework 1 442 may forward the message to service framework 2 443. Service framework 1 442 may identify service framework 2 443 as the recipient of the message based on inspecting the message for the target identifier identifying the service framework 2 443.

Step 409: Service framework 2 443 may receive the message. Because service framework 2 443 does not include a temporary binding of the second UE context data identifier ID (B) , service framework 2 443 may perform NFS instance selection. NFS instance selection may include choosing a recipient NFS instance within the associated NFS set (e.g., NFS set 2 438) . Service framework 2 443 may perform instance selection on NFS set 2 based on the target identifier indicating SF2 443.

Step 410: Service framework 2 443 may forward the message to the selected NFS instance. For purposes of illustration, in the embodiment as illustrated in FIG. 4, the selected NFS instance is NFS5 435. The message may include a target identifier that is set to NULL.

Step 411: NFS5 435 may receive the message. In some embodiments, NFS5 435 may not include UE context data. In these embodiments, NFS5 may create a second UE context data and allocate a second UE context data identifier (ID (B) ) to identify the second UE context data in NFS set 2 438. The NFS 5 may store the first UE context data identifier ID (A) and the service framework 1 identification information ID (SF1) .

Step 412: NFS5 435 may transmit a create UE binding request to service framework 2 443. The create UE binding request may include the second UE context data identifier ID (B) and NFS identification information indicative of NFS5 435 (ID (NFS5) ) . The create UE binding request may instruct SF2 443 to store the data included within the create UE binding request.

Step 413: SF2 443 may store the temporary binding, where the temporary binding may associate the second UE context data identifier ID (B) and the NFS identification information indicative of NFS5 435 (ID (NFS5) ) .

Step 414: SF2 443 may transmit a create UE binding acknowledgement to NFS5 435. The create UE binding acknowledgement may indicate that the temporary binding was stored at SF 2443.

Step 415: The NFS5 435 may transmit a message to SF2 443, where the message includes an intended recipient of communication peer NFS1 431. The target identifier may indicate SF1 442, represented by ID (SF1) . The message may include the first UE context data identifier ID (A) and the target identifier ID (SF1) . In some embodiments, the message may include the second UE context data identifier ID (B) and the service framework 2 443 identification information ID (SF2) .

Step 416: Service framework 2 443 may forward the message to service framework 1 442. Service framework 2 443 may identify SF1 442 as the recipient of the message based on inspecting the message for the target identifier identifying the SF1 442.

Step 417: SF1 442 may receive the message from SF2 443. SF1 442 may access the stored temporary binding information associating the first UE context data identifier ID (A) and the NFS information indicative of NFS1 431. Based on the temporary binding information, SF1 may forward the message to NFS1 431. Upon forwarding the message to NFS1 431, SF1 442 may modify the target ID to the first UE context data identifier ID (A) .

Step 418: NFS1 431 may identify the first UE context data by inspecting the message for the first UE context data identifier ID (A) . NFS1 431 may store the second UE context data identifier ID (B) and the SF2 443 identification information ID (SF2) for use in subsequent communication.

Step 419: NFS1 431 may transmit a subsequent message to SF1 442 with a recipient of communication peer NFS5 435. The target identifier may indicate SF2 443 identification information ID (SF2) and the second UE context data identifier ID (B) .

Step 420: Service framework 1 442 may forward the subsequent message to service framework 2 443. Service framework 1 442 may identify service framework 2 443 as the recipient of the message based on inspecting the message for the target identifier identifying service framework 2 443.

Step 421: SF2 443 may receive the subsequent message and determine the recipient as communication peer NFS5 435 based on the temporary binding stored in SF2 443 associating the second UE context data identifier ID (B) and NFS information indicative of NFS5 435. Upon forwarding the subsequent message to NFS5 435, SF2 443 may set the target identifier to the second UE context data identifier ID (B) .

Example Embodiment 3

FIG. 5 illustrates an exemplary signaling process 500 for re-establishing a communication session. In the embodiment as shown in FIG. 5, a NFS instance (e.g., NFS5 535) is out of service. In this embodiment, the communication peer (NFS1 531) does not need to know that its communication peer NFS5 535 is out of service to continue communication with another NFS instance in a NFS set. Accordingly, the service logic may be simplified.

Step 501: In this embodiment, communication peer (NFS5 535) is out of service.

Step 502: NFS5 535 may transmit a service de-registration request to SF2 543 to indicate to SF2 542 that NFS5 535 is out of service. The service de-registration request may include identification information indicative of NFS5 535, which may be represented as ID (NFS5) .

Step 503: SF2 543 may remove all temporary binding information associating the second UE context data identifier ID (B) and the NFS5 535 identification information. SF2 543 may transmit a service de-registration response to NFS5 535 indicating that the temporary binding information has been removed.

Step 504: NFS1 531 may transmit a message to SF1 542. The target identifier in the message may include the second UE context data identifier ID (B) and service framework 2 543 identification information ID (SF2) .

Step 505: SF1 542 may forward the message to SF2 543. SF1 542 may forward the message to SF2 543 based on the target identifier in the message including SF2 identification information ID (SF2) .

Step 506: SF2 543 may receive the message and determine that there is no temporary binding information relating to the second UE context data based on the message target identifier including the second UE context data identifier ID (B) . SF2 543 may perform instance selection to select a NFS instance within NFS set 2 that is indicated by ID (SF2) . In this embodiment, SF2 543 selects NFS4 534 as the communication peer during instance selection.

Step 507: SF2 543 may transmit the message toward the selected NFS instance, NFS4 534. The target identifier of the message may be set to the second UE context data identifier ID (B) .

Step 508: NFS4 534 may receive the message, and NFS4 534 may determine that it does not include the second UE context data associated with the second UE context data identifier ID (B) . Accordingly, NFS4 534 may retrieve the second UE context data identified by the second UE context data identifier ID (B) from the UDSF2 540.

Step 509: NFS4 534 may transmit a create UE Binding request (ID (B) , ID (NFS4) ) to SF2 543. The create UE binding request may include instructions to the SF2 543 to store the temporary binding between the second UE context data identifier ID (B) and NFS4 534 identification information ID (NFS4) .

Step 510: SF2 543 may store the temporary binding information received in the create UE binding request (ID (B) and ID (NFS4) ) .

Step 511: SF2 543 may transmit a create UE binding acknowledgement to NFS4 534 indicating that the temporary binding information has been stored at SF2 543.

Step 512: NFS4 534 may transmit the message to SF2 543. The target identifier of the message may be set to the received first UE context data identifier ID (A) and SF1 identification information ID (SF1) .

Step 513: SF2 543 may forward the received message to SF1 542 based on the target identifier.

Step 514: SF1 542 may receive the message and determine that it includes a temporary binding between the first UE context data identifier ID (A) and information indicative of NFS1 531. Accordingly, SF1 542 forwards the message to NFS1 531. The target identifier is set to the first UE context data identifier ID (A) .

Step 515: NFS1 531 may receive the message and identify the first UE context data by using the first UE context data identifier ID (A) . When the communication terminates, the NFS1 531 may store the UE context data into the UDSF1 539 and release the UE context. The temporary binding may be released from SF1 542.

Example Embodiment 4

FIG. 6 illustrates an exemplary signaling process 600 for re-establishing a communication session for NFS1 to communicate with a target.

Step 601: NFS1 631 may store a first UE context data in the UDSF1 639. A first UE context data identifier ID (A) may uniquely identify the first UE context data in NFS set 1 637.

Step 602: NFS1 631 may transmit a Release UE Binding request to the SF1 642. The release UE binding request may include the first UE context data identifier ID (A) .

Step 603: SF1 642 may remove the temporary binding associating the first UE context data identifier ID (A) and identification information indicative of NFS1 631 ID (NFS1) .

Step 604: SF1 642 may transmit a Release UE Binding acknowledgement to the NFS1 631.

Step 605: NFS5 635 may store the UE context data in UDSF2 640. The second UE context data may be uniquely identified by the second UE context data identifier ID (B) in NFS Set 2 638.

Step 606: NFS5 635 may transmit a Release UE Binding request to SF2 643. The release UE binding request may include the second UE context data identifier ID (B) .

Step 607: SF2 643 may remove the temporary binding associating the second UE context data identifier ID (B) and identification information indicative of NFS5 635 ID (NFS5) .

Step 608: SF2 may transmit a Release UE Binding acknowledgment to NFS5. In some embodiments, steps 605-608 may be performed simultaneously as with steps 601-604.

Step 609: During a new procedure, NFS2 632 may be selected to be a communication peer. The NFS2 632 may retrieve the first UE context data identified by ID (A) from the UDSF1 639.

Step 610: NFS2 632 may transmit a UE registration request (ID (A) , ID (NFS2) ) to the SF1 642. This step is used to store the temporary binding in SF1 642 associating the first UE context data identifier ID (A) and information indicative of NFS2 632 ID (NFS2) .

Step 611: SF1 642 may store the temporary binding (ID (A) , ID (NFS2) ) .

Step 612: SF1 642 may transmit UE registration Ack to NFS2 632 acknowledging that the temporary binding has been stored at SF1 642.

Step 613: NFS2 632 may transmit a message to the SF1 642. The target ID is set to the second UE context data identifier ID (B) and information indicative of SF2 643 ID (SF2) .

Step 614: SF1 642 may forward the message to SF2 643 based on the target ID.

Step 615: SF2 643 may not include a temporary binding of the second UE context data identifier ID (B) . Accordingly, SF2 643 may perform the instance selection in the NFS Set 2 638 which was indicated by the ID (SF2) . In some embodiments, SF2 643 may select NFS4 634 as the communication peer.

Step 616: SF2 643 may forward the message to the selected service instance NFS4 634. The target ID is set to ID (B) .

Step 617: NFS4 634 may not include the second UE context, therefore the NFS4 634 may retrieve the UE context data identified by ID (B) from the UDSF2 640.

Step 618: NFS4 634 transmits a Create UE Binding (ID (B) , ID (NFS4) ) to SF2 643. SF2 643 may store the temporary binding between the second UE context data identifier ID (B) and identification information identifying NFS4 634.

Step 619: SF2 643 may store the temporary binding (ID (B) , ID (NFS4) ) .

Step 620: SF2 643 may transmit a Create UE Binding Acknowledgement to NFS4 634 indicating that the temporary binding has been stored by SF2 643.

Step 621: NFS4 634 may transmit the message back to SF2 643. The target identifier is set to the first UE context data identifier ID (A) and information indicative of SF1 ID (SF1) .

Step 622: SF2 643 forwards message to SF1 642 according to the target identifier.

Step 623: SF1 642 receives the message and determines that it has the temporary binding associating ID (A) and ID (NFS1) . Accordingly, SF1 642 forwards the message to NFS1 631. The target identifier may be set to ID (A) . The NFS1 631 may identify the first UE context data by using the ID (A) and handle the message.

FIG. 7 shows a flow chart representation of a method 700 for wireless communication. The method 700 includes, at 702, allocating, by the SF, a SF identifier identifying the SF. The method also includes, at 704, transmitting, by the SF, the SF identifier to the NFS.

In some embodiments, the method includes receiving, by the SF, a network function service (NFS) identifier identifying a NFS and a context data identifier identifying a context data, and storing, by the SF, the context data identifier and the NFS identifier. This may be illustrated by steps 402-403 in Example Embodiment 2, for example.

In some embodiments, the SF identification information identifies a set of NFS instances. The set of NFS instances may include the first NFS set 237 or second NFS set 238 as described in FIG. 2, for example.

In some embodiments, the method further includes receiving, by the SF, a message including a target SF identifier, determining, by the SF, a target SF associated with the target SF identifier, and forwarding, by the SF, the message to target SF identified by the target SF identifier. This may be illustrated in steps 407 and 408 of Example Embodiment 2, for example.

In some embodiments, the method further includes including, by the SF, the target identifier in the message to indicate the context data identifier. The target identifier may include the target identifier provided by NRF 441 in Step 406 in Example Embodiment 2, for example.

In some embodiments, the message includes the context data identifier and the SF identifier identifying the SF, and wherein the message is configured to be stored at a peer NFS.

In some embodiments, the second SF is associated with a second set of NFS instances, and the peer NFS is included within the second set of NFS instances. The second set of NFS instances may include NFS set 2 238 in FIG. 2, for example.

In some embodiments, the method further includes receiving, by the SF, a de-registration message from the NFS that includes the NFS identifier, and removing all context data identifiers related to the NFS identifier at the SF. The SF may receive a service de-registration request indicating a request to remove the context data identifier and the NFS identification information stored at the SF in step 502 of Example Embodiment 3, for example.

In some embodiments, the method further includes receiving, by the SF, a message including the context data identifier, determining, by the SF, that the context data identifier and NFS identification information has been removed from the SF, performing, by the SF, instance selection to select a selected NFS among NFS instances within the set of NFS instances, and transmitting, by the SF, the message to the selected NFS, wherein the message includes the SF identifier identifying the SF. This may be illustrated by

steps

409 and 410 of Example Embodiment 2, for example.

In some embodiments, the method further includes receiving, by the SF, the context data identifier and selected NFS identification information identifying the selected NFS, and storing, by the SF, the context data identifier and selected NFS identification information identifying the selected NFS. This may be illustrated in step 411 of Example Embodiment 2, for example.

In some embodiments, the method further includes receiving, by the SF, a release binding request from the NFS, where the release binding request includes the context data identifier, and removing, by the SF, the context data identifier and the NFS identifier. This may be illustrated in

steps

602 and 603 in Example Embodiment 4, for example.

FIG. 8 shows a flow chart representation of a method 800 for wireless communication. The method 800 includes, at 802, receiving, by a network function service (NFS) , a service framework (SF) identification information that identifies a SF. The method also includes, at 804, transmitting, by the NFS, a NFS service profile and the SF identification information identifying the SF to a network function repository function (NRF) .

In some embodiments, the method further includes allocating, by the NFS, a context data identifier to identify a set of context data. This may be illustrated in step 401 of Example Embodiment 2, for example.

In some embodiments, the method further includes transmitting, by the NFS, a request for the set of context data to an unstructured data storage function (UDSF) , and receiving, by the NFS, the set of context data from the UDSF. This may be illustrated in step 609 of Example Embodiment 4, for example.

In some embodiments, the UDSF allocates the context data identifier to identify the set of context data.

In some embodiments, the method further includes transmitting, by the NFS, the context data identifier and the NFS service profile to the SF, where the SF is configured to store the context data identifier and the NFS service profile. This may be illustrated in step 402 of Example Embodiment 2, for example.

In some embodiments, the method further includes transmitting, by the NFS, a target identifier request to the NRF to identify a target type, and receiving, by the NFS, the target type indicating a second SF. This may be illustrated in steps 405-406 of Example Embodiment 2, for example.

In some embodiments, the NFS is included within a set of NFS instances, wherein each NFS included within the set of NFS instances are connected to the SF.

In some embodiments, the method further includes transmitting, by the NFS, a message to the SF, wherein the message is destined for a peer NFS located within a second NFS set, and wherein the SF is configured to forward the message to the second SF based on the target identifier indicating the second SF included in the message.

In some embodiments, the message includes the context data identifier and the SF identification information.

In some embodiments, the method further includes determining, by the NFS, that the NFS is out of service; transmitting, by the NFS, a de-registration message to the SF, where the de-registration message instructs the SF to remove all context data identifiers related to the NFS service profile stored at the SF. This may be illustrated in steps 501-502 of Example Embodiment 3, for example.

In some embodiments, the method further includes transmitting, by the NFS, a release binding request to the SF, where the release binding request includes the context data identifier, wherein the SF is configured to remove the context data identifier and the NFS service profile based on the release binding request. This may be illustrated by steps 602-603 of Example Embodiment 4, for example.

FIG. 9 shows an example of a wireless communication system where techniques in accordance with one or more embodiments of the present technology can be applied. A wireless communication system 900 can include one or more base stations (BSs) 905a, 905b, one or

more wireless devices

910a, 910b, 910c, 910d, and a core network 925. A base station 905a, 905b can provide wireless service to

wireless devices

910a, 910b, 910c and 910d in one or more wireless sectors. In some implementations, a base station 905a, 905b includes directional antennas to produce two or more directional beams to provide wireless coverage in different sectors.

The core network 925 can communicate with one or more base stations 905a, 905b. The core network 925 provides connectivity with other wireless communication systems and wired communication systems. The core network may include one or more service subscription databases to store information related to the subscribed

wireless devices

910a, 910b, 910c, and 910d. A first base station 905a can provide wireless service based on a first radio access technology, whereas a second base station 905b can provide wireless service based on a second radio access technology. The base stations 905a and 905b may be co-located or may be separately installed in the field according to the deployment scenario. The

wireless devices

910a, 910b, 910c, and 910d can support multiple different radio access technologies.

In some implementations, a wireless communication system can include multiple networks using different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that could be used to connect to different wireless networks.

FIG. 10 is a block diagram representation of a portion of a hardware platform. A hardware platform 1005 such as a network device or a base station or a wireless device (or UE) can include processor electronics 1010 such as a microprocessor that implements one or more of the techniques presented in this document. The hardware platform 1005 can include transceiver electronics 1015 to send and/or receive wired or wireless signals over one or more communication interfaces such as antenna 1020 or a wireline interface. The hardware platform 1005 can implement other communication interfaces with defined protocols for transmitting and receiving data. The hardware platform 1005 can include one or more memories (not explicitly shown) configured to store information such as data and/or instructions. In some implementations, the processor electronics 1010 can include at least a portion of the transceiver electronics 1015. In some embodiments, at least some of the disclosed techniques, modules or functions are implemented using the hardware platform 1005. The various functions described herein, e.g., the SF, the NFS, etc. may be implemented on the hardware platform 1005.

It is thus evident that techniques are disclosed for communicating between service frameworks. Using the techniques described herein, a service framework may establish a temporary binding between a network function service and a UE context data identifier identifying UE context data, thereby reducing service framework complexity.

From the foregoing, it will be appreciated that specific embodiments of the presently disclosed technology have been described herein for purposes of illustration, but that various modifications may be made without deviating from the scope of the invention. Accordingly, the presently disclosed technology is not limited except as by the appended claims.

The disclosed and other embodiments, modules and the functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document) , in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code) . A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit) .

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

While this patent document contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

Only a few implementations and examples are described, and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

A method for wireless communication, comprising:

allocating, by a service framework (SF) , a SF identifier identifying the SF; and

transmitting, by the SF, the SF identifier to the NFS.
The method of claim 1, further including:

receiving, by the SF, a network function service (NFS) identifier identifying a NFS and a context data identifier identifying a context data; and

storing, by the SF, the context data identifier and the NFS identifier.
The method of claim 1, wherein the SF identifier identifies a set of NFS instances.
The method of claim 1, further including:

receiving, by the SF, a message including a target SF identifier;

determining, by the SF, a target SF associated with the target SF identifier; and

forwarding, by the SF, the message to the target SF identified by the target SF identifier.
The method of claim 4, further including:

including, by the NFS, the target SF identifier in the message to indicate the target SF.
The method of claim 4, wherein the message includes the context data identifier and the SF identifier identifying the SF, and wherein the context data identifier and the SF identifier are configured to be stored at a peer NFS.
The method of claim 6, wherein the target SF is associated with a second set of NFS instances, and wherein the peer NFS is associated with the second set of NFS instances.
The method of claim 2, further including:

receiving, by the SF, a de-registration message from the NFS that includes the NFS identifier; and

removing, by the SF, all context data identifiers related to the NFS identifier.
The method of claim 2, further including:

receiving, by the SF, a message including the context data identifier;

determining, by the SF, that the context data identifier and NFS identifier has been removed from the SF;

performing, by the SF, instance selection to select a selected NFS among NFS instances within a set of NFS instances; and

transmitting, by the SF, the message to the selected NFS, wherein the message includes the context data identifier.
The method of claim 9, further including:

receiving, by the SF, the context data identifier and a selected NFS identifier identifying the selected NFS; and

storing, by the SF, the context data identifier and the selected NFS identifier identifying the selected NFS.
The method of claim 2, further including:

receiving, by the SF, a release binding request from the NFS, where the release binding request includes the context data identifier; and

removing, by the SF, the context data identifier and the NFS identifier.
A method for wireless communication, comprising:

receiving, by a network function service (NFS) , a service framework (SF) identifier identifying a SF; and

transmitting, by the NFS, a NFS service profile and the SF identifier identifying the SF to a network function repository function (NRF) .
The method of claim 12, further including:

allocating, by the NFS, a context data identifier to identify a UE context data.
The method of claim 12, further including:

transmitting, by the NFS, a request for UE context data to an unstructured data storage function (UDSF) ; and

receiving, by the NFS, the UE context data from the UDSF.
The method of claim 14, wherein the UDSF allocates the context data identifier to identify the UE context data.
The method of claim 13, further including:

transmitting, by the NFS, the context data identifier and the NFS service profile to the NRF, where the NRF is configured to store the context data identifier and the NFS service profile.
The method of claim 12, further including:

transmitting, by the NFS, a target identifier request to the NRF to identify a target type; and

receiving, by the NFS, the target identifier identifying a second SF.
The method of claim 12, wherein the NFS is included within a set of NFS instances, wherein each NFS included within the set of NFS instances are connected to the SF.
The method of claim 17, further including:

transmitting, by the NFS, a message to the SF, wherein the message is destined for a peer NFS located within a second NFS set, and wherein the SF is configured to forward the message to the second SF based on the target identifier indicating the second SF included in the message.
The method of claim 19, wherein the message includes the context data identifier and the SF identifier.
The method of claim 13, further including:

transmitting, by the NFS, a de-registration message to the SF, where the de-registration message instructs the SF to remove all context data identifiers related to the NFS service profile stored at the SF.
The method of claim 13, further including:

transmitting, by the NFS, a release binding request to the SF, where the release binding request includes the context data identifier, wherein the SF is configured to remove the context data identifier and the NFS service profile based on the release binding request.
An apparatus for wireless communication comprising a processor that is configured to carry out the method of any of claims 1 to 22.
A non-transitory computer readable medium having code stored thereon, the code when executed by a processor, causing the processor to implement a method recited in any of claims 1 to 22.