CN112997455A

CN112997455A - Communication method for service framework

Info

Publication number: CN112997455A
Application number: CN201880099463.4A
Authority: CN
Inventors: 朱进国; 梁爽
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2021-06-18
Anticipated expiration: 2038-11-14
Also published as: WO2020034465A1; CN112997455B

Abstract

Methods, systems, and devices related to digital wireless communications are disclosed, and more particularly, methods, systems, and devices related to techniques related to communicating between multiple service frameworks are disclosed. In one exemplary aspect, a method of wireless communication includes: network Function Service (NFS) identification information to identify an NFS and a context data identifier to identify context data are received by a Service Framework (SF). The method also includes assigning, by the SF, 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 sending, by the SF, an SF identifier to the NFS.

Description

Communication method for service framework

Technical Field

This patent document relates generally to wireless communications.

Background

Mobile communication technology is pushing the world to an increasingly interconnected and networked society. Rapid development of mobile communications and advances in technology have resulted in greater demands for capacity and connectivity. Other aspects such as energy consumption, equipment cost, spectral efficiency and latency are also important to meet the needs of various communication scenarios. Various techniques are being discussed, including new methods for providing higher quality of service.

Disclosure of Invention

This document discloses methods, systems, and devices related to digital wireless communications, and more particularly, to methods, systems, and devices related to techniques for reporting User Equipment (UE) capabilities when the UE is connected to multiple network nodes.

In one exemplary aspect, a method of wireless communication is disclosed. The method includes assigning, by a Service Framework (SF), a SF identifier identifying the SF. The method also includes sending, by the SF, the SF identifier to the NFS.

In another exemplary aspect, a method of 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 sending, by the NFS, the NFS service profile and an SF identifier identifying the SF to a network function storage module (NRF).

In another exemplary aspect, a wireless communications apparatus is disclosed that includes a processor. The processor is configured to implement the methods 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 drawings, the drawings, and the description below. Other features should be apparent from the description and drawings, and from the claims.

Drawings

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

Fig. 2 illustrates a communication environment.

Figure 3 illustrates exemplary signaling processing for a service registration procedure and an NRF registration/update procedure.

Fig. 4 illustrates an exemplary signaling process for establishing a communication session between an NFS instance and a service framework.

Fig. 5 illustrates an exemplary signaling process for reestablishing a communication session.

Fig. 6 illustrates an exemplary signaling process for reestablishing a communication session for NFS1 to communicate with a target.

Fig. 7 shows a flowchart representation of a wireless communication method.

Fig. 8 shows a flowchart representation of a method of wireless communication.

Fig. 9 illustrates an example of a wireless communication system to which techniques in accordance with one or more embodiments of the present technology may be applied.

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

Detailed Description

The development of a new generation of wireless communications (5G New Radio (NR) communications) is part of a continuing mobile broadband evolution process to meet the demands of ever-increasing network demands. NR will provide greater throughput to allow more users to connect simultaneously. Other aspects such as energy consumption, equipment cost, spectral efficiency and latency are also important to meet the needs of various communication scenarios.

With the advent of NR in the wireless domain, a UE will be able to support both protocols simultaneously. Fig. 1 shows an exemplary schematic diagram of a system architecture for Dual Connectivity (DC). The current base station in the core network 103, referred to as the first network element 101, may select a suitable base station for the UE100 to use as the second network element 102. For example, a suitable base station may be selected by comparing the channel quality of the base station to a predetermined threshold. Both base stations may provide radio resources to the UE100 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., an Xn interface) interconnects the two network elements. On the radio interface side, the first and second network elements (101 and 102) may use the same or different Radio Access Technologies (RATs) to provide radio resources. Each network element may independently schedule transmissions with the UE 100. A network element having a control plane connection to the core network is referred to as a primary node (e.g., the first network element 101), while a network element having only a user plane connection to the core network is referred to as a secondary node (e.g., the second network element 102). In some cases, the UE100 may connect to more than two nodes, with one node acting as a primary node and the remaining nodes acting as secondary nodes.

In some embodiments, the UE may support LTE-NR Dual Connectivity (DC). For example, one of the typical LTE-NR dual connectivity architectures may be set up as follows: the primary 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 to an Evolved Packet Core (EPC) network (e.g., LTE core network). The architecture shown in fig. 1 may also be modified to include various master/slave node configurations. For example, the NR RAN node may be a primary node and the LTE RAN node may be a secondary node. In this case, the core network for the main NR RAN node is the next generation converged network (NG-CN).

One or more NFS instances may be connected to a service framework. One or more service frameworks can be included in 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 to facilitate communication between NFS instances located in different NFS sets. The serving framework may store a UE context data identifier that identifies the UE context data and NFS identification information that indicates the NFS. The association between the UE context data identifier identifying the UE context data and the NFS identification information indicating the NFS may be referred to as a "temporary binding". Temporary bindings may not affect the capacity expansion and contraction of an NFS centralized service instance, as well as ongoing sessions sent to other network function instances. The section headings are for ease of understanding only and do not limit the embodiments disclosed in each section to only that section. Furthermore, examples of terms and protocols used in 5G networks are used to aid understanding, and the disclosed techniques may be applied to other wireless systems implementing other communication protocols.

Fig. 2 illustrates a communication environment 200. As shown in fig. 2, a plurality of Network Function Services (NFSs) may be included in environment 200. The NFS (e.g., NFS 1231) in this environment may be referred to as an "NFS instance. Each NFS instance may process service logic and expose the service to other authorized NFS instances in environment 200.

In some embodiments, one or more NFS instances are grouped into an NFS set. For illustration purposes, as shown in fig. 2, NFS 1231, NFS 2232, and NFS 3233 are grouped into NFS set 1237. Similarly, for illustration purposes, NFS 4234, NFS 5235, and NFS 6236 are grouped into NFS set 2238, as shown in fig. 2. In each NFS set (e.g., NFS set 1237), the capabilities of each NFS are substantially similar. In other words, each NFS instance in the NFS set (e.g., NFS 1231, NFS 2232, NFS 3233 in NFS set 1237) can access the same data set stored in the data storage entity (e.g., unstructured data storage function 1(UDSF1) 239). Thus, each NFS instance in the NFS set can process the UE transaction because each NFS instance can access context data (e.g., UE context data).

As shown in FIG. 2, environment 200 may include a network function storage module (NRF) 241. NRF 241 may support service discovery within the same service framework or between multiple Service Frameworks (SFs). NRF 241 may maintain an NFS profile that includes all available NFS instances and corresponding supported services and service frameworks. In some embodiments, NRF 241 receives an NFS discovery request from an NFS (e.g., NFS 1241). In response to the request, NRF 241 may send information of the discovered NFS instance to the NFS (e.g., NFS 1231) that sent the request.

Environment 200 may include one or more service frameworks. Service frameworks (e.g., service framework 1242 and service framework 2243) may perform registration and discovery functions and communicate between NFS instances. In some embodiments, each service framework may be implemented in an operator network using various mechanisms and may support various models of distribution and connectivity with network function services.

Example embodiment 1

Figure 3 illustrates an exemplary signaling process 300 for a service registration procedure and an NRF registration/update procedure. An NFS (e.g., NFS 1331) may communicate with service framework 342 and with NRF 341 via service framework 342.

Step 301: NFS331 may be activated for the first time. NFS331 as described with respect to fig. 3 may also be referred to as an "NF service instance consumer.

Step 302: NFS331 may register with service framework 342. NFS331 may initiate registration by sending a service registration request to service framework 342. The service registration request can include NFS set identification information indicating that the NFS set is identified in the communication environment. For example, the NFS set identification information may identify NFS set 1237 as shown in fig. 2. The service registration request may also include NFS identification information indicating an NFS (such as NFS331 in fig. 3). The NFS identification information may be represented as an ID (NFS 1). NFS set identification information and NFS identification information may be used by service framework 342 to forward information to an identified NFS located in an identified NFS set.

Step 303: service framework 342 may store NFS identification information that enables routing of information to an NFS associated with service framework 342. In some embodiments, service framework 342 may assign an SF identification to uniquely identify service framework 342 and the associated set of NFSs. The SF identity may be denoted as id (SF). The SF identification can identify service framework 342 in a communication environment that includes a plurality of service frameworks and NFS sets. For example, the SF identification may identify service framework 1 (or simply "SF 1") 242 as shown in fig. 2. The SF identification may be used to forward information to the NFS instance associated with the identified service framework 342.

Service framework 342 may send a service registration response to NFS331 to indicate a successful registration. The service registration response may include the SF identification of service framework 342.

Step 304: NFS331 may send an NRF registration/update request to NRF 341. The NRF registration/update request may include information representing a request to register information associated with NFS331 with NRF 341. The NRF registration/update request may include the NFS profile and SF identification received from service framework 342 as depicted in step 303. The NFS profile may include information indicating the NFS331 (such as available NF service instances and their supported services).

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

Step 305: NRF 341 may receive an NRF registration/update request. NRF 341 may store an NFS profile and an SF identification associated with the NFS profile. After receiving and/or successfully storing the NFS profile and SF identification, NRF 341 may send an NRF registration/update response to NFS331 to indicate that the registration was successful.

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

Example embodiment 2

Fig. 4 illustrates an exemplary signaling process 400 for establishing a communication session between an NFS instance and a service framework. In this example embodiment, NFS1 and NFS5 may not store information related to a peer NFS. In contrast, NFS1 and NFS5 may store target identities and target SF identities that uniquely identify a set of target NFSs. Thus, the capacity expansion and contraction of any NFS (e.g., NFS 1431) does not affect the communication peer NFS (e.g., NFS 435) and the service framework complexity is reduced.

Step 401: NFS1431 may assign a first UE context data identity. The first UE context data identity may also be denoted as "id (a)". The first UE context data identification 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 the NFS1431, the NFS1431 allocates a first UE context data identity to identify the UE context data. In other embodiments, the NFS1431 may request the UDSF 1439 to allocate a first UE context data identity to identify the UE context data.

In some embodiments, the UE context data may be stored in the UDSF (e.g., USDF 1439). If the communication session is active in the NFS1431 and the NFS1431 does not have UE context data, but the UDSF 1439 already stores UE context data, the NFS1431 may retrieve the UE context data from the UDSF 1439. After this step, the UE context data may include a temporary binding to the NFS 1431.

Step 402: NFS1431 may send a create UE binding request to service framework 1442. The create UE binding request may include a first UE context data identification (ID (a)) and NFS identification information (ID (NFS1)) indicating NFS1431 as described herein. The create UE binding request may instruct SF 1442 to store the temporary binding identified by the first UE context data in SF 1442.

Step 403: SF 1442 may store a temporary binding between the first UE context data identification (ID (a)) and NFS identification information indicating NFS1431 (ID (NFS 1)).

Step 404: the SF 1442 may send a create UE binding acknowledgement to the NFS 1431. Creating the UE binding acknowledgement may indicate that the temporary binding is stored at SF 1442.

Step 405: in some embodiments, NFS1 sends an NRF discovery request to NRF 441. The NRF discovery request may include a target NFS type, where the target NFS type indicates an NFS type that will be an appropriate communication peer with NFS 1.

Step 406: in some embodiments, NRF441 may determine the 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 the NFS set. For example, the target identifier may identify a service framework 2 ("SF 2") 443 associated with NFS set 2438. The destination identifier may be represented as an ID (SF 2). When determining the target identifier, when NFSs in the NFS set 2 are registered in the NRF441, the NRF441 may store an ID (SF 2). The NRF441 may transmit an NRF discovery response message indicating a target identifier (e.g., ID (SF 2)).

Step 407: NFS1431 sends a message to SF 1442. The message includes a destination identifier ID (SF2), which may be used by SF 1442 to forward the message to SF 2443 identified in the destination identifier. The message may include first UE context data identification id (a) and SF1 identification information to identify SF 1442 as being associated with first UE context data identification id (a). The service framework 1 identification information may be referred to as an ID (SF 1). The first UE context data identification id (a) and SF1 identification information may be stored in a peer NFS (e.g., NFS 5435) for subsequent communications.

Step 408: service framework 1442 may forward the message to service framework 2443. Service framework 1442 may identify service framework 2443 as a recipient of the message based on examining the message to obtain a destination identifier that identifies service framework 2443.

Step 409: service framework 2443 may receive the message. Because serving framework 2443 does not include the temporary binding for second UE context data identifier id (b), serving framework 2443 may perform NFS instance selection. NFS instance selection may include selecting a recipient NFS instance within an associated NFS set (e.g., NFS set 2438). Service framework 2443 may perform instance selection for NFS set 2 based on the target identifier indicating SF 2443.

Step 410: service framework 2443 may forward the message to the selected NFS instance. For purposes of illustration, in the embodiment shown in fig. 4, the selected NFS instance is NFS 5435. The message may include a destination identifier set to NULL.

Step 411: NFS 5435 may receive the message. In some embodiments, NFS 5435 may not include UE context data. In these embodiments, NFS5 may create second UE context data and assign a second UE context data identifier (id (b)) to identify the second UE context data in NFS set 2438. NFS5 may store a first UE context data identifier ID (a) and a service framework 1 identification information ID (SF 1).

Step 412: NFS 5435 may send create UE binding request to service framework 2443. The create UE binding request may include a second UE context data identifier ID (b) and NFS identification information (ID (NFS5)) indicating NFS 5435. The create UE binding request may instruct SF 2443 to store data included in the create UE binding request.

Step 413: SF 2443 may store a temporary binding, wherein the temporary binding may associate the second UE context data identifier ID (b) with NFS identification information indicating NFS 5435 (ID (NFS 5)).

Step 414: SF 2443 may send a create UE binding acknowledgement to NFS 5435. The create UE binding acknowledgement may indicate that the temporary binding is stored at SF 2443.

Step 415: NFS 5435 may send a message to SF 2443, where the message includes the intended recipient of communication peer NFS 1431. The target identifier may indicate SF 1442 represented by ID (SF 1). The message may include a first UE context data identifier ID (a) and a target identifier ID (SF 1). In some embodiments, the message may include a second UE context data identifier ID (b) and a service framework 2443 identification information ID (SF 2).

Step 416: service framework 2443 may forward the message to service framework 1442. Service framework 2443 can identify SF 1442 as a recipient of a message based on examining the message for a target identifier that identifies SF 1442.

Step 417: SF 1442 may receive a message from SF 2443. The SF 1442 may access stored temporary binding information associating a first UE context data identifier id (a) with NFS information indicating NFS 1431. Based on the temporary binding information, SF1 may forward the message to NFS 1431. SF 1442 may modify the target ID to the first UE context data identifier ID (a) when forwarding the message to NFS 1431.

Step 418: NFS1431 may identify the first UE context data by examining a message for a first UE context data identifier id (a). NFS1431 may store a second UE context data identifier ID (b) and a SF 2443 identification information ID (SF2) for subsequent communications.

Step 419: the sending NFS1431 may send a subsequent message to the SF 1442, targeted to the communication peer NFS 5435. . The target identifier may indicate SF 2443 identification information ID (SF2) and second UE context data identifier ID (b).

Step 420: service framework 1442 may forward subsequent messages to service framework 2443. Service framework 1442 may identify service framework 2443 as a recipient of the message based on examining the message for a target identifier that identifies service framework 2443.

Step 421: SF 2443 may receive the subsequent message and determine the receiver as communication peer NFS 5435 based on a temporary binding stored in SF 2443 associating the second UE context data identifier id (b) with NFS information indicating NFS 5435. SF 2443 may set the target identifier to the second UE context data identifier id (b) when forwarding subsequent messages to NFS 5435.

Example embodiment 3

Fig. 5 illustrates an exemplary signaling process 500 for reestablishing a communication session. In the embodiment shown in fig. 5, an NFS instance (e.g., NFS 5535) is out of service. In this embodiment, the communication peer (NFS1531) need not know that its communication peer NFS 5535 has ceased service to continue communicating with another NFS instance in the NFS set. Thus, the service logic can be simplified.

Step 501: in this embodiment, the communication peer (NFS 5535) has stopped service.

Step 502: NFS 5535 may send a service de-registration request to SF 2543 to indicate to SF 2542 that NFS 5535 is out of service. The service deregistration request may include identification information indicating the NFS 5535, which may be denoted as an ID (NFS 5).

Step 503: the SF 2543 may remove all temporary binding information associating the second UE context data identifier id (b) with the NFS 5535 identification information. The SF 2543 may send a service deregistration response to the NFS 5535 indicating that the temporary binding information has been removed.

Step 504: NFS1531 may send a message to SF 1542. The target identifier in the message may include a second UE context data identifier ID (b) and a service framework 2543 identification information ID (SF 2).

Step 505: SF 1542 may forward the message to SF 2543. SF 1542 may forward the message to SF 2543 based on the target identifier in the message including SF2 identification information ID (SF 2).

Step 506: the SF 2543 may receive the message and determine that there is no temporary binding information related to the second UE context data based on the target identifier in the message comprising the second UE context data identifier id (b). SF 2543 may perform instance selection to select an NFS instance in NFS set 2 indicated by ID (SF 2). In this embodiment, SF 2543 selects NFS 4534 as the communication peer during instance selection.

Step 507: SF 2543 may send a message to the selected NFS instance (NFS 4534). The target identifier of the message may be set to the second UE context data identifier id (b).

Step 508: NFS 4534 may receive the message, and NFS 4534 may determine that it does not include second UE context data associated with a second UE context data identifier id (b). Thus, NFS 4534 may retrieve the second UE context data identified by the second UE context data identifier id (b) from UDSF 2540.

Step 509: NFS 4534 may send a create UE binding request (ID (b), (ID) (NFS4)) to SF 2543. Creating the UE binding request may include an instruction to SF 2543 to store a temporary binding between the second UE context data identifier ID (b) and the NFS 4534 identification information ID (NFS 4).

Step 510: SF 2543 may store the temporary binding information (ID (b) and ID (NFS4)) received in the create UE binding request.

Step 511: SF 2543 may send a create UE binding acknowledgement to NFS 4534 indicating that temporary binding information has been stored at SF 2543.

Step 512: NFS 4534 may send a message to SF 2543. A target identifier of the message may be set to the received first UE context data identifier ID (a) and SF1 identification information ID (SF 1).

Step 513: SF 2543 may forward the received message to SF 1542 based on the target identifier.

Step 514: SF 1542 may receive the message and determine that it includes a temporary binding between the first UE context data identifier id (a) and the information indicating the NFS 1531. Thus, SF 1542 forwards the message to NFS 1531. The target identifier is set to the first UE context data identifier id (a).

Step 515: NFS1531 may receive the message and identify the first UE context data by using a first UE context data identifier, id, (a). When the communication is terminated, the NFS1531 may store the UE context data to the UDSF 1539 and release the UE context. The temporary binding may be released from SF 1542.

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: the NFS1631 may store the first UE context data in the UDSF 1639. The first UE context data identifier id (a) may uniquely identify the first UE context data in the NFS set 1637.

Step 602: the NFS1631 may send a release UE binding request to the SF 1642. The release UE binding request may include a first UE context data identifier id (a).

Step 603: the SF 1642 may remove the temporary binding associating the first UE context data identifier ID (a) with the identification information indicating the NFS1631 (ID (NFS 1)).

Step 604: the SF 1642 may send a release UE binding acknowledgement to the NFS 1631.

Step 605: NFS5635 may store UE context data in UDSF 2640. The second UE context data may be uniquely identified by a second UE context data identifier id (b) in the set of NFS 2638.

Step 606: NFS5635 may send a release UE binding request to SF 2643. The release UE binding request may include a second UE context data identifier id (b).

Step 607: SF 2643 may remove the temporary binding associating second UE context data identifier ID (b) with identification information indicating NFS5635 (ID (NFS 5)).

Step 608: the SF2 may send a release UE binding acknowledgement to the NFS 5. In some embodiments, step 605-608 may be performed simultaneously as step 601-604.

Step 609: during the new process, NFS 2632 may be selected as a communication peer. The NFS 2632 may retrieve the first UE context data identified by the id (a) from the UDSF 1639.

Step 610: the NFS 2632 may send a UE registration request (ID (a), ID (NFS2)) to the SF 1642. This step is used to store in SF 1642 a temporary binding associating the first UE context data identifier ID (a) with information indicating NFS 2632 (ID (NFS 2)).

Step 611: the SF 1642 may store the temporary binding (ID (A), ID (NFS 2)).

Step 612: SF 1642 may send a UE registration Ack to NFS 2632, which confirms that the temporary binding is stored in SF 1642.

Step 613: the NFS 2632 may send a message to the SF 1642. The target ID is set to the second UE context data identifier ID (b) and information indicating SF 2643 ID (SF 2).

Step 614: SF 1642 may forward the message to SF 2643 based on the target ID.

Step 615: SF 2643 may not include a temporary binding for the second UE context data identifier id (b). Thus, SF 2643 may perform instance selection in NFS set 2638 indicated by ID (SF 2). In some embodiments, SF 2643 may select NFS 4634 as the communication peer.

Step 616: the SF 2643 may forward the message to the selected service instance NFS 4634. The target ID is set to ID (b).

Step 617: NFS 4634 may not include the second UE context, so NFS 4634 may retrieve the UE context data identified by id (b) from UDSF 2640.

Step 618: NFS 4634 sends create UE binding (ID (b), ID (NFS4)) to SF 2643. SF 2643 may store a temporary binding between the second UE context data identifier id (b) and the identification information identifying NFS 4634.

Step 619: the SF 2643 may store temporary bindings (ID (b), ID (NFS 4)).

Step 620: SF 2643 may send a create UE binding acknowledgement to NFS 4634 indicating that the temporary binding has been stored by SF 2643.

Step 621: NFS 4634 may send a message back to SF 2643. The target identifier is set to a first UE context data identifier ID (a) and information indicating SF1 ID (SF 1).

Step 622: the SF 2643 forwards the message to the SF 1642 according to the destination identifier.

Step 623: SF 1642 receives the message and determines that it has a temporary binding associating ID (a) with ID (NFS 1). Thus, SF 1642 forwards the message to NFS 1631. The target identifier may be set to id (a). The NFS1631 may identify the first UE context data and process the message by using the id (a).

Fig. 7 shows a flowchart representation of a wireless communication method 700. The method 700 includes, at 702, assigning, by an SF, an SF identifier that identifies the SF. The method also includes transmitting, by the SF, the SF identifier to the NFS, at 704.

In some embodiments, the method includes receiving, by the SF, a Network Function Service (NFS) identifier identifying the NFS and a context data identifier identifying the context data, and storing, by the SF, the context data identifier and the NFS identifier. This can be illustrated, for example, by

steps

402 and 403 in example embodiment 2.

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

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 the target SF identified by the target SF identifier. This may be illustrated, for example, in

steps

407 and 408 of example embodiment 2.

In some embodiments, the method further comprises including the target identifier in the message by the SF to indicate the context data identifier. For example, the target identifier may include the target identifier provided by NRF441 in step 406 in example embodiment 2.

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

In some embodiments, the second SF is associated with a second set of NFS instances, and the peer NFS is included in the second set of NFS instances. For example, the second set of NFS instances may include NFS set 2238 in fig. 2.

In some embodiments, the method further includes receiving, by the SF, a de-registration message from the NFS including the NFS identifier, and removing, at the SF, all context data identifiers related to the NFS identifier. For example, the SF may receive a service deregistration 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.

In some embodiments, the method further includes receiving, by the SF, a message including a context data identifier, determining, by the SF, that the context data identifier and the NFS identification information have 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 sending, by the SF, the message to the selected NFS, wherein the message includes an SF identifier that identifies the SF. This can be illustrated, for example, by steps 409 and 410 of example embodiment 2.

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 the selected NFS identification information identifying the selected NFS. This may be illustrated, for example, in step 411 of example embodiment 2.

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

steps

602 and 603 of example embodiment 4.

Fig. 8 shows a flowchart representation of a wireless communication method 800. The method 800 includes, at 802, receiving, by a Network Function Service (NFS), Service Framework (SF) identification information identifying a SF. The method also includes, at 804, sending, by the NFS, the NFS service profile and SF identification information identifying the SF to a network functional storage module (NRF).

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

In some embodiments, the method further includes sending, by the NFS, a request for the context data set to an Unstructured Data Storage Function (UDSF), and receiving, by the NFS, the context data set from the UDSF. This may be illustrated, for example, in step 609 of example embodiment 4.

In some embodiments, the UDSF assigns a context data identifier to identify the context data set.

In some embodiments, the method further comprises sending, by the NFS, the context data identifier and the NFS service profile to the SF, wherein the SF is configured to store the context data identifier and the NFS service profile. This may be illustrated, for example, in step 402 of example embodiment 2.

In some embodiments, the method further includes sending, by the NFS, a target identifier request to the NRF to identify the target type, and receiving, by the NFS, the target type indicating the second SF. This can be illustrated, for example, in

step

405 and 406 of example embodiment 2.

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

In some embodiments, the method further includes sending, by the NFS, a message to the SF, wherein the message is addressed to a peer NFS located in the second set of NFSs, 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 a context data identifier and SF identification information.

In some embodiments, the method further comprises determining, by the NFS, that the NFS is out of service; sending, by the NFS, a deregistration message to the SF, wherein the deregistration message instructs the SF to remove all context data identifiers related to NFS service profiles stored at the SF. This can be illustrated, for example, in step 501-502 of example embodiment 3.

In some embodiments, the method further comprises sending, by the NFS, a release binding request to the SF, wherein the release binding request comprises 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 can be illustrated, for example, by step 602-603 of example embodiment 4.

Fig. 9 illustrates an example of a wireless communication system in which techniques in accordance with one or more embodiments of the present technology may be applied. The wireless communication system 900 may include one or more Base Stations (BSs) 905a, 905b, one or more wireless devices 910a, 910b, 910c, 910d, and a core network 925. Base stations 905a, 905b may provide wireless service to wireless devices 910a, 910b, 910c, and 910d in one or more wireless sectors. In some embodiments, base stations 905a, 905b include directional antennas to generate two or more directional beams to provide wireless coverage in different sectors.

The core network 925 may be in communication with one or more base stations 905a, 905 b. The core network 925 provides a connection 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 subscribed wireless devices 910a, 910b, 910c, and 910 d. The first base station 905a may provide wireless service based on a first radio access technology, while the second base station 905b may provide wireless service based on a second radio access technology. The base stations 905a and 905b may be quasi-collocated, depending on the deployment scenario, or may be installed separately in the field, depending on the deployment scenario. Wireless devices 910a, 910b, 910c, and 910d may support multiple different radio access technologies.

In some embodiments, a wireless communication system may include multiple networks using different wireless technologies. A dual-mode or multi-mode wireless device includes two or more wireless technologies that can 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 wireless device (or UE), may include processor electronics 1010, such as a microprocessor, that implements one or more of the techniques presented in this document. Hardware platform 1005 may include transceiver electronics 1015 to transmit and/or receive wired or wireless signals over one or more communication interfaces (e.g., antenna 1020 or a wired interface). Hardware platform 1005 may implement other communication interfaces for sending and receiving data using the defined protocols. Hardware platform 1005 may include one or more memories (not explicitly shown) configured to store information such as data and/or instructions. In some embodiments, the processor electronics 1010 may 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 a hardware platform 1005. Various functions described herein (e.g., SF, NFS, etc.) may be implemented on the hardware platform 1005.

Thus, it is apparent that techniques for communicating between service frameworks are disclosed. Using the techniques described herein, a serving framework may establish a temporary binding between a network function service and a UE context data identifier that identifies UE context data, thereby reducing serving framework complexity.

From the foregoing, it will be appreciated that specific embodiments of the 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 disclosed technology is not limited, except as by the appended claims.

The disclosed embodiments, as well as other embodiments, modules, and functional operations described in this document, may 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 embodiments and other embodiments may 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 of 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 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 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 executing 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 various 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 disks 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 described combination can in some cases be excised from the combination, and the 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 some embodiments and examples are described and other embodiments, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1. A method for wireless communication, the method comprising:

assigning, by a Service Framework (SF), a SF identifier identifying the SF; and

sending, by the SF to the NFS, the SF identifier.

2. The method of claim 1, further comprising:

receiving, by the SF, a Network Function Service (NFS) identifier identifying an NFS and a context data identifier identifying context data; and

storing, by the SF, the context data identifier and the NFS identifier.

3. The method of claim 1, wherein the SF identifier identifies a set of NFS instances.

4. The method of claim 1, further comprising:

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.

5. The method of claim 4, further comprising:

including, by the NFS, the target SF identifier in the message to indicate the target SF.

6. 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.

7. 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.

8. The method of claim 2, further comprising:

receiving, by the SF from the NFS, a deregistration message including the NFS identifier; and

removing, by the SF, all context data identifiers related to the NFS identifier.

9. The method of claim 2, further comprising:

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

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

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

transmitting, by the SF to the selected NFS, the message, wherein the message includes the context data identifier.

10. The method of claim 9, further comprising:

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

storing, by the SF, the context data identifier and a selected NFS identifier that identifies a selected NFS.

11. The method of claim 2, further comprising:

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

removing, by the SF, the context data identifier and the NFS identifier.

12. A method for wireless communication, the method comprising:

receiving, by a Network Function Service (NFS), a Service Framework (SF) identifier identifying a SF; and

sending, by the NFS, an NFS service profile and the SF identifier identifying the SF to a network function storage module (NRF).

13. The method of claim 12, further comprising:

assigning, by the NFS, a context data identifier to identify UE context data.

14. The method of claim 12, further comprising:

sending, 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.

15. The method of claim 14, wherein the UDSF allocates the context data identifier to identify the UE context data.

16. The method of claim 13, further comprising:

transmitting, by the NFS, the context data identifier and the NFS service profile to the NRF, wherein the NRF is configured to store the context data identifier and the NFS service profile.

17. The method of claim 12, further comprising:

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

receiving, by the NFS, a target identifier identifying a second SF.

18. The method of claim 12, wherein the NFS is included in a set of NFS instances, wherein each NFS included in the set of NFS instances is connected to the SF.

19. The method of claim 17, further comprising:

transmitting, by the NFS, a message to the SF, wherein the message is addressed to a peer NFS located in a second set of NFSs, 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.

20. The method of claim 19, wherein the message comprises the context data identifier and the SF identifier.

21. The method of claim 13, further comprising:

sending, by the NFS, a deregistration message to the SF, wherein the deregistration message instructs the SF to remove all context data identifiers related to the NFS service profile stored at the SF.

22. The method of claim 13, further comprising:

sending, by the NFS, a release binding request to the SF, wherein 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.

23. An apparatus for wireless communication, comprising a processor configured to perform the method of any of claims 1-22.

24. A non-transitory computer-readable medium having code stored thereon, which when executed by a processor, causes the processor to implement the method of any of claims 1-22.