CN113348687B

CN113348687B - Communication between service frameworks in wireless communications

Info

Publication number: CN113348687B
Application number: CN201880100615.8A
Authority: CN
Inventors: 梁爽; 朱进国
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2022-09-16
Anticipated expiration: 2038-11-14
Also published as: CN113348687A; WO2020034467A1

Abstract

Methods, systems, and devices related to digital wireless communications are disclosed, and more particularly, techniques related to communicating between NFS instances over multiple service frames are disclosed. In one exemplary aspect, a method for wireless communication includes generating a context data index of context data associated with a terminal. The method further comprises sending the context data index to a Service Framework (SF). In another exemplary aspect, a method for wireless communication includes receiving a context data index and Network Function Service (NFS) identification information identifying an NFS instance. The method also includes generating a unique route ID corresponding to the context data index. The method also includes storing a first mapping between the context data index and the route ID, and a second mapping between the route ID and the NFS identification information.

Description

Communication between service frameworks in wireless communications

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. The rapid growth 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, techniques related to communicating between NFS instances over multiple service frames.

In one exemplary aspect, a method for wireless communication is disclosed. The method includes generating a context data index of context data associated with the terminal. The method further comprises sending the context data index to a Service Framework (SF).

In another exemplary aspect, a method for wireless communication is disclosed. The method includes receiving a context data index and Network Function Service (NFS) identification information identifying an NFS instance. The method also includes generating a unique route ID corresponding to the context data index. The method also includes storing a first mapping between the context data index and the route ID, and a second mapping between the route ID and the NFS identification information.

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

Fig. 3 illustrates an exemplary signaling procedure for generating or obtaining a UE context index and/or a route ID.

Fig. 4 illustrates an exemplary signaling procedure using a route ID during service communication between NFS instances via a service framework.

Fig. 5 shows an exemplary signaling procedure for releasing a route ID.

Fig. 6 shows a signaling procedure for reassigning a route ID.

Fig. 7 shows a signaling procedure in which the route ID is reassigned.

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

Fig. 9 shows a flowchart representation of a method for wireless communication.

Fig. 10 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. 11 is a block diagram representation of a portion of a hardware platform.

Detailed Description

The development of a new generation of wireless communication, 5G new air interface (NR), is part of the mobile broadband continuous evolution process that meets the growing 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 dual-connection (DC) system architecture. A current base station in the core network 103, referred to as a first network element 101, may select a suitable base station for the UE 100 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 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., 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 of the network elements may independently schedule transmissions with the UE 100. The network elements having a control plane connection to the core network are referred to as primary nodes (e.g., the first network element 101), and the network elements having a user plane connection only to the core network are referred to as secondary nodes (e.g., the second network element 102). In some cases, the UE 100 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 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 a variety of 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 of the main NR RAN node is the next generation converged network (NG-CN).

For the LTE and NR protocols in LTE-NR DC, the UE capability consists of two parts: the universal capability of the UE is suitable for single connection scenes of LTE and NR protocols; and the frequency band combination capability of the UE, related to the dual connectivity scenario. When a UE has multiple simultaneous connections with a network node, the frequency bands for the different network nodes must cooperate with each other regardless of the RAT type used. Here, the term "cooperative" means that the UE can operate in the frequency band without any collision or substantial interference — that is, the frequency bands can coexist. For example, the third generation partnership project (3GPP) standards specify a set of frequency band combinations that can cooperate with each other. If band 1 and band 2 are not designated as valid band combinations, the UE cannot communicate with node 1 using band 1 and node 2 using band 2 at the same time.

This patent document describes techniques that may be implemented for communicating between two network function service instances. The techniques described herein may not include a long session binding between two service instances. Route IDs may be introduced during communication between NFS instances over different service frameworks. Thus, the in/out expansion of each service instance in the NFS set does not affect the sessions between other NFS instances. In addition, the routing information may be separate from the UE identification information. The topology inside the service framework domain may not be exposed to other service frameworks.

Fig. 2 illustrates a communication environment 200. As shown in fig. 2, a plurality of Network Function Services (NFSs) may be included within environment 200. An NFS (e.g., NFS 1231) in an 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 within environment 200.

In some embodiments, one or more NFS instances are grouped into one NFS set. For purposes of illustration, as shown in fig. 2, NFS 1231, NFS 2232, and NFS 3233 are grouped into NFS set 1237. Similarly, for purposes of illustration, NFS 4234, NFS 5235, and NFS 6236 are grouped into NFS set 2238, as shown in fig. 2. Within each NFS set (e.g., NFS set 1237), the capabilities of each NFS are substantially similar. In other words, each NFS instance within the NFS set (e.g., NFS 1231, NFS 2232, NFS 3233 within NFS set 1237) can access the same data stored within the data storage entity (e.g., unstructured data storage function 1(UDSF1) 239). Thus, each NFS instance within the set of NFSs may process the UE transaction because 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. NRF 241 may support service discovery between multiple Service Frameworks (SFs). NRF 241 may maintain an NFS profile that includes all available NFS instances and the 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 communication between NFS instances. In some embodiments, each service framework may be implemented in an operator network using various mechanisms and may support multiple distribution patterns and connections with network function services.

Example embodiment 1

Fig. 3 illustrates an exemplary signaling procedure 300 for generating or obtaining a UE context index and/or a route ID.

Step 301: NFS 1331 may receive UE-related messages. NFS 1331 may also be referred to as NF/service instance 1. NFS 1331 may determine whether a UE context for the UE-related message exists. If NFS 1331 determines that no UE context exists in NFS 1331, NFS 1331 may obtain the UE context from UDSF 339.

Step 302: NFS 1331 may send a content request to UDSF 339. The content request may instruct UDSF 339 to determine whether it stores the UE context.

Step 303: UDSF 339 can send a content response to NFS 1331. In some embodiments, if UDSF 339 includes a UE context, UDSF 339 may send the UE context to NFS 1331 in a content response message. The UE context may include a route identifier (or "route ID") and a UE context index (or "context data index"). The routing identifier may be used to identify NFS 1331, and the UE context index may uniquely identify the UE context.

In some embodiments, UDSF 339 does not include a UE context. In these embodiments, UDSF 339 may generate a UE context and assign a UE context index to the UE context. UDSF 339 may return the UE context and UE index to NFS 1331 in a content response.

Step 304: NFS 1331 may determine whether a routing identifier exists. The routing identifier may be used to route messages between instances (e.g., NFS 1331). The binding between the route ID and the instance ID may be dynamic. In some embodiments, if an NFS instance (e.g., NFS 1331) has a valid route ID included in the UE context, NFS 1331 may send a modify bind request to instruct SF 342 to bind NFS 1331 to the route ID.

Step 305: NFS instance (NFS 1331) may send a create bind request to Service Framework (SF) 342. The created binding request may instruct the SF 342 to obtain a route identifier assigned by the SF 342. The create/modify binding request to SF 342 may include the UE context index. The SF 342 may store a UE context index, a route ID, and NFS identification information (instance ID).

In some embodiments, if the UE context (or "context data") is released locally at NFS 1331, the route ID is included as part of the UE context. NFS 1331 may send the UE context and route ID to UDSF 339 for storage at UDSF 339. If another NFS instance (e.g., NFS 2332) in the same set acquires the UE context from UDSF 339, the NFS instance (e.g., NFS 2332) may send a modify binding request to SF 342 to update the binding at SF 342.

Step 306: SF 342 may send create/modify responses to NFS 1331. If the SF 342 determines that a valid route ID has been used for the UE context index included in the create/modify binding request, the SF 342 may reuse the route ID and include the route ID in the create/modify response to NFS 1331. In some embodiments, the route ID may be reused when a previous NFS instance (e.g., NFS 1331) in a set (e.g., NFS set 1337) fails, and another NFS instance (e.g., NFS 2332) within the set acquires the UE context from UDSF 339, as reusing the route ID may reduce exchanges between NFS consumers and NFS producer communication peers.

In some embodiments, as shown in fig. 2, one or more NFS instances may share the same SF. One or more NFS sets (e.g., NFS set 1237 in fig. 2) may share a common SF (e.g., SF 1242 in fig. 2). All NFS sets that share a SF may be referred to as NFS units (e.g., NFS unit 1244 in fig. 2).

To identify the UE context within the NFS unit, an NFS Set identifier (Set ID) may be used. The UE context index and the NFS set identifier may uniquely identify the UE context in the NFS set.

The set ID may be generated by one of UDSF 339, an NFS instance (e.g., NFS 1331), or SF 342. In some embodiments, if the set ID is added by UDSF 339, the set ID may also be included in the UE context. The NSF instance (NFS 1331) may store a set ID. In these embodiments, the NFS instance (NFS 1331) may include the set ID in a create binding request issued to SF 342, where SF 342 may store the UE index and the set ID.

In some embodiments, if the set ID is added by the NFS instance (NFS 1331), the NFS instance (NFS 1331) may decide whether to store the set ID in the UE context and pass the set ID from the NFS1 to UDSF 339 when the UE context is released locally. Thus, UDSF 339 may not include a set ID. NFS 1331 may also send the set ID to SF 342 by creating a bind request. The SF 342 may store a UE context index and a set ID.

In some embodiments, if the set ID is generated by SF 342, SF 342 may generate the set ID based on mechanisms such as NFS instance identification information, NFS instance configuration, and the like. SF 342 may add the set ID to the route ID and send the set ID and route ID to the NFS instance (NFS 1331) via create/modify response. The SF 342 may store a UE context index and a set ID. In some embodiments, the set ID may be a separate parameter or included as part of the UE context index or part of the route ID.

Any of

steps

304 and 306 may be performed when creating a UE context in an NFS instance (e.g., NFS 1331). In some embodiments, steps 304-306 may also be performed before an NFS instance initiates a service request (e.g., the service request in step 405 of example embodiment 2) to another NFS instance.

Example embodiment 2

Step 401: service consumer 1431 (or "NFS consumer 1431") may send a discovery request to NRF 441. The discovery request may include a target NFS type that identifies the desired NFS instance as a peer NFS instance in communication with service consumer 1431. The discovery request may be sent before the NFS consumer 1431 initiates the discovery request, and the service consumer 1431 does not include information about any NFS producer as a communication peer. In some embodiments, a secondary input may also be included. For example, if the access and mobility management function (AMF) request is a Session Management Function (SMF) instance, then Data Network Name (DNN) and location information may also be included.

Step 402: NRF 441 may send a discovery response to service consumer 1431. The discovery response may include a target ID indicating that the NFS producer is the communication peer with the service consumer 1431. NRF 441 may determine the target ID based on the target NFS type transmitted in the discovery request using load balancing or other similar techniques. For purposes of illustration, the target ID may indicate the service producer 2432 as the target ID and the communication peer. The target ID may include an instance ID that includes information identifying an SF (e.g., SF 2443) and information identifying an NFS producer set (NFS set 2438). In some embodiments, the target ID is configured to be routed to SF 2443, where SF 2443 may select a service producer (e.g., service producer 1432). In some embodiments,

steps

403 and 404 may be skipped if service consumer 1431 has already created a binding between the route ID and the instance ID.

Steps 403 and 404: service consumer 1431 may determine whether a binding is created between the route ID and the instance ID that identifies service consumer 1431. In some embodiments, if service consumer 1 determines that a binding between the route ID and the instance ID should be created, service consumer 1431 may send a create binding/modify binding request to SF 442, as described in example embodiment 1, step 304-. Service consumer 1431 may receive the create/modify bind response from SF 442.

In some embodiments, a different UE context index may be used for each SF unit (e.g., SF 1442 and SF 2443). For example, a serving consumer UE context index (UE-SC-index) may identify a UE context in an NFS cell associated with SF 1442. Similarly, a service producer UE context index (UE-SP-index) may identify a UE context in an NFS unit associated with SF 2443.

In some embodiments, a different route ID may be used for each SF unit (e.g., SF 1442 and SF 2443). For example, service consumer Routing ID (SC-Routing ID) identifies the Routing ID associated with NFS consumer 1431. Similarly, the service producer route ID (SP-Routing ID) identifies the route ID associated with the NFS producer 1432.

Step 405: service consumer 1431 may send a service request message to SF 1442. The service request message may include a target ID, where SF1 may use the target ID to route the message to SF 2443. The service response message may include a UE context identifier (UE ID) identifying the UE context. The message may also include an SC1-Routing-ID, where the NFS producer (service producer 1432) may identify the service consumer 1431 in a response message to the service consumer 1431. In some embodiments,

step

406 and 407 may be skipped if the service producer 1432 has created a binding/mapping between the route ID and the instance ID.

SF 1442 may route the message to SF 2443 based on the target ID identifying SF 2443. SF 2443 may receive the service request message from SF 1431. In some embodiments, if the target ID only indicates SF 2443 associated with NFS set 2438, SF 2443 may select an NFS producer instance based on load balancing or similar techniques. As shown in fig. 4, for example, SF 2443 may select service producer 1432 as the selected NFS producer instance. In these embodiments, SF 2443 may forward the message to the selected service producer (e.g., service producer 1432).

Steps 406 and 407: the service producer 1432 may determine whether it has a UE context. In some embodiments, if the service producer 1432 does not include a UE context, the service producer 1432 may obtain the UE context from the UDSF as described in step 301-. In some embodiments, if the service producer 1432 includes a valid UE context, interaction with the UDSF may be skipped.

The service producer 1432 may determine whether to generate a binding/mapping between the route ID and the instance ID. If there is no binding between the route ID and the instance ID, the service producer 1432 may send a create bind/modify bind request to the SF2 using the techniques described in step 304-306 in example embodiment 1.

In some embodiments, SF 2443 may assign service producer route ID (SP1-Routing-ID) to service producer 1432. SF 2443 may send create binding response message to service producer 1432, where the message includes SP 1-Routing-ID. The SF 2443 may maintain a mapping between the UE-SP-index ID and the SP 1-Routing-ID. SP1-Routing-ID includes information to route the message to SF 2443.

Step 408: the service producer 1432 may send a service response message to the SF 2443. The service response message may include SC1-Routing-ID, where SF 2443 may route the message to SF 1442 using SC1-Routing ID. The service response message may include a SP1-Routing-ID for the service consumer 1431 to route any subsequent messages to the NFS producer 1432.

SF 1442 may receive the service response message. SF 1442 may determine that the message should be forwarded to service consumer 1431 based on the UE-SC-index mapped to SC1-Routing ID included in the service response message. SF 1442 may forward the service response message to service consumer 1431.

In some embodiments, step 409-. In some embodiments,

steps

409 and 410 and 411 may be performed separately.

Step 409: service consumer 1 may send a service request message to SF 1442. The message may include the SP1-Routing-ID for Routing to SF 1442. SF 1442 may forward the message to SF 2443 based on SP 1-Routing-ID.

The SF 2443 may receive the request message and determine the UE-SP-index based on the mapping between the SP1-Routing-ID and the UE-SP-index. SF 2443 may forward the message to service producer 1.

Step 410: service producer 1432 may send a service response message to SF 2443. The message may include a SC1-Routing-ID used to route the message to SF 1442. SF 2443 may route the message to SF 1442 based on SC 1-Routing-ID.

The SF 1442 may receive the response message and find the UE-SC-index based on the SC 1-Routing-ID. SF 1442 may forward the message to service consumer 1431.

Step 411: service producer 1432 may send a notification message to SF 2443. The notification message may be sent based on an event occurrence (e.g., timer expiration). The notification message may include SC1-Routing-ID that may be used for Routing to SF 1442. SF 2442 may forward the notification message to SF 1442 based on SC 1-Routing-ID.

The SF 1442 may receive the notification message and determine the UE-SC-index based on the SC 1-Routing-ID. SF 1442 may forward the message to service consumer 1431 based on the UE-SC-index mapped to SC 1-Routing-ID.

Example embodiment 3

Fig. 5 shows an exemplary signaling procedure for releasing a route ID.

Step 501: the NFS 1531 may decide to release the UE context and pass the UE context to the UDSF 539. An event occurrence, such as a release message reception from another NFS instance, timer expiration, or O & a, may trigger NFS 1531 to release the UE context.

Step 502: the NFS 1531 may send a deliver context request to the UDSF 539. The transfer context request may include a UE context and a UE context index (e.g., UE-SC-index in example embodiment 2). The UDSF 539 may store UE context and UE context index.

Step 503: the UDSF 539 may send a deliver content response to the NFS 1531. The deliver content response may include an indication that the UDSF 539 stores the UE context. If there are some routing IDs in other elements, these IDs may also be included in the UE context and passed to the UDSF.

Step 504-505: NFS 1531 may send a modify binding request to SF 1542. The modify binding request may instruct SF 1542 to release a mapping between the instance ID and the route ID allocated by SF 1542. SF 1542 may ensure that no route ID values are reassigned for instances in other sets to avoid incorrect routing. The mapping between UE-Index and route ID may not be released by SF 1542. The SF 1542 may send a modified binding response indicating that the SF 1542 releases the mapping between the instance ID and the route ID.

Example embodiment 4

Fig. 6 shows a signaling procedure for reassigning a route ID. In example embodiment 4, the service producer 1 route ID SP1-Routing ID may have been released and the service consumer 1631 may send a service request in which a new service producer NFS instance is selected.

Step 601: service consumer 1(NFS consumer 1)631 can send a service request message to SF 1642. The service request may include a UE-SP-Index. The message may include the SP1-Routing-ID for Routing to SF 2643. SF 1642 may route the message to SF 2643 based on SP 1-Routing-ID.

Step 602: SF 2643 may receive the request message and determine that there is no NFS instance mapped with SP 1-Routing-ID. In response, SF 2643 may select a service producer NFS instance based on the aggregation information included in SP 1-routing-ID. For illustration purposes, SF 2643 may select service producer 2633 as the selected service producer NFS instance. SF 2643 may select an NFS instance from the set (e.g., NFS producer 2633) using load balancing or other similar techniques. In some embodiments, the SF 2643 may find the UE-SP-Index based on the SP 1-route ID and obtain the set information based on the UE-SP-Index. The SF 2643 may forward the service request message to the NFS producer 2633.

If the SF 2643 selects a new NFS instance, the binding between that instance and the route ID may be updated. When the service producer 2633 receives the request, the service producer 2633 may find the UE context based on the UE-SP-Index. The service producer 2633 may reuse the SP route ID included in the UE context. In some embodiments, for example, when service producer 2633 reuses the SP route ID, binding updates between service producer 2633 and SF 2643 may be skipped, as described in steps 603-.

Step 603: the service producer 2633 may determine whether it has a UE context. If there is no UE context, the service producer 2633 may obtain the UE context from the UDSF using the techniques as described in steps 301-. Service producer 2633 may determine whether to create a binding between the route ID and the instance ID. If there is no binding between the route ID and the instance ID, the service producer 2633 may initiate a create bind/modify bind request to SF 2643 using the techniques described in step 304-. The service producer 2633 may determine whether it has a valid route ID. If there is no valid route ID, the service producer 2633 may send a create/modify bind request to obtain the route ID, as described in step 304-306 in example embodiment 1.

Step 604: the SF 2643 may send a create/modify bind response to the service producer 2633. The create/modify binding response may include the SP 1-Routing-ID.

Step 605: service producer 2633 may send a service response message to SF 2643. The message may include the SC1-Routing-ID for Routing to SF 1642. SF 2643 may route the message to SF 1642 based on SC 1-Routing-ID.

Step 606: the SF 1642 may receive the response message and find the UE-SC-index based on the SC 1-Routing-ID. SF1 may forward the message to service consumer 1631.

If there is a subsequent or successor message between the service consumer 1631 and the service producer 2633, steps 607- > 611 can be performed. In some embodiments, steps 607-610 and 611-612 may be performed separately.

Step 607: service consumer 1631 may send a service request message to SF 1642. The message may include the SP1-Routing-ID for Routing to SF 1642. SF 1642 may route the message to SF 2643 based on SP 1-Routing-ID.

Step 608: the SF 2643 may receive the request message from the SF 1642 and find the UE-SP-index mapped to the SP 1-Routing-ID. SF 2643 may forward the message to service producer 2633.

Step 609: service producer 2633 may send a service response message to SF 2643. The message may include the SC1-Routing-ID, which may be used for Routing to SF 1642. SF 2643 may route the message to SF 1642 based on SC 1-Routing-ID.

Step 610: SF 1642 may receive the response message and find UE-SC-index based on SC 1-Routing-ID. SF 1642 may forward the message to service consumer 1631.

Step 611: service producer 2633 may send a notification message to SF 2643. The notification message may be sent based on an event occurrence. The message may include the SC1-Routing-ID, which may be used for Routing to SF 1643. SF 2643 may route the message to SF 1642 based on SC 1-Routing-ID.

Step 612: the SF 1642 may receive the notification message and find the UE-SC-index based on the SC 1-Routing-ID. SF 1642 may forward the message to service consumer 1631.

Example 5

Figure 7 shows a signalling procedure for reallocating Routing-ids. In example embodiment 5, SC 1-route ID may have been released, NFS producer 2733 may send a notify request and may select a new NFS instance.

Step 701: service generator 1731 may send a notification message to SF 2743. The message may include SC1-Routing-ID for forwarding the message to SF 1742. SF 2743 may route the message to SF 1742 based on SC 1-Routing-ID.

Step 702: SF 1742 may receive the notification message and determine that there is no NFS instance mapped with SC 1-Routing-ID. Thus, SF 1742 may select an NFS instance (e.g., service consumer 1731) based on the aggregated information included in SC 1-routing-ID. In some embodiments, SF 1742 may find the UE-SC-Index based on SC 1-route ID and obtain set information based on the UE-SC-Index. SF 1742 may select an NFS instance from the set (e.g., NFS consumer 1) using load balancing. SF 1742 may forward the message to service consumer 1731.

If the SF 1742 selects a new NFS instance, the binding between the instance and the route ID may be updated. The notification message may include the UE-SP-Index. When service consumer 1731 receives the message, service consumer 1731 may determine a UE context based on the UE-SC-Index. In some embodiments, service consumer 1731 may reuse the SC route ID in the UE context. In these embodiments, the binding between update service consumer 1731 and SF 1742 may be skipped.

Step 703-704: service consumer 1731 may check if it has a UE context. If there is no UE context, service consumer 1731 may obtain the UE context from the UDSF as described in step 301-.

Service consumer 1731 may check whether it has a valid route ID. If there is no valid route ID, service consumer 1 may initiate a create/modify binding request to obtain a route ID using the techniques described in

step

304 and 306 of example embodiment 1.

Fig. 8 shows a flowchart representation of a method 800 for wireless communication. The method 800 includes, at 802, generating a context data index of context data associated with a terminal. The method also includes, at 804, sending the context data index to a Service Framework (SF).

In some embodiments, the context data index is stored at an Unstructured Data Storage Function (UDSF) and SF.

In some embodiments, the generating step is performed by one of a Network Function Service (NFS) instance or a UDSF.

In some embodiments, the method includes sending, by the NFS instance, a request to the UDSF, and receiving, by the NFS instance, context data and a context data index from the UDSF. This can be shown, for example, in step 302-303 in example embodiment 1.

In some embodiments, the method includes sending, by the SF to the NFS instance, a routing identifier identifying the NFS instance. For example, sending the routing identifier may be shown in step 306 in example embodiment 1.

In some embodiments, the routing identifier is included in the context data.

In some embodiments, the method includes sending, by the NFS instance to the SF, at least one of a routing identifier and an NFS instance identifier that identifies the NFS instance. This may be illustrated, for example, in step 305 of example embodiment 1.

In some embodiments, the method includes storing, by the SF, a first mapping between an NFS instance identifier and a routing identifier that identifies the NFS instance.

In some embodiments, the method includes storing, by the SF, a second mapping between the context data index and the route identifier.

In some embodiments, one of the NFS instance, UDSF, or SF generates a set identifier that identifies a set of NFS instances within a unit, where the unit includes one or more sets of NFS instances. For example, an NFS set may be illustrated by NFS set 1237 in fig. 2, and an NFS unit may be illustrated by NFS unit 1244 in fig. 2.

In some embodiments, the context data index and the set identifier uniquely identify the context data within a cell.

In some embodiments, the method includes receiving, by the NFS instance, a set identifier from the UDSF.

In some embodiments, the method includes sending, by the NFS instance, a set identifier to the SF, wherein the SF is configured to store the content data index and the set identifier.

In some embodiments, the method includes sending, by an NFS instance, a discovery request to a network function repository function (NRF) instructing the NRF to identify a peer NFS instance, and receiving, by the NFS instance, a target identifier from the NRF, wherein the target identifier identifies the peer NFS instance. The discovery request and the response may be illustrated, for example, by steps 401-402 in embodiment 2.

In some embodiments, the target identifier identifies a set identifier of the peer NFS instance and the second SF.

In some embodiments, the target identifier identifies the second SF and a peer NFS instance identifier that identifies a peer NFS instance.

In some embodiments, the method includes sending, by the NFS instance, a message to the SF, wherein the message includes a destination identifier, a routing identifier, and UE identification information. This message may be illustrated, for example, by a service request as shown in step 405 in embodiment 2.

In some embodiments, the SF is configured to forward the message to a second SF based on the target identifier.

In some embodiments, the method includes receiving, by the NFS instance, a response message including a second route identifier identifying a peer NFS instance and a second SF, and sending, by the NFS instance, a subsequent message to the SF, wherein the message includes the second route identifier, wherein the second route identifier indicates the SF to forward the subsequent message to the second SF.

In some embodiments, the method includes releasing, by the NFS instance, the route identifier and the NFS instance identifier, and sending, by the NFS instance, the route identifier to the UDSF. This can be shown, for example, in

step

502 and 503 in example embodiment 3.

In some embodiments, the method includes sending, by the NFS instance to the SF, a release message indicating the SF to remove the routing identifier and the NFS instance identifier identifying the NFS instance. The release message may be illustrated, for example, by the modify binding request message in step 504 of embodiment 3.

Fig. 9 shows a flowchart representation of a method 900 for wireless communication. The method 900 includes, at 902, receiving a context data index and Network Function Service (NFS) identification information identifying an NFS instance. The method further includes, at 904, generating a unique route ID corresponding to the context data index. The method also includes, at 906, storing a first mapping between the context data index and the route ID and a second mapping between the route ID and the NFS identification information.

In some embodiments, the method includes releasing the second mapping upon receiving a request from a Service Framework (SF).

In some embodiments, the context data index identifies context data.

In some embodiments, the method includes sending, by the NFS instance, a request to the UDSF, and receiving, by the NFS instance, context data including a context data index and a route ID from the UDSF. This can be shown, for example, in step 302-303 in example embodiment 1.

In some embodiments, the method includes receiving a request message from the SF indicating a request for a route ID, and sending, by the SF, the route ID to the NFS instance. This can be shown, for example, in step 305-306 in example embodiment 1.

In some embodiments, one of the NFS instance, UDSF, or SF generates a set identifier that identifies a set of NFS instances within a unit, where the unit includes one or more sets of NFS instances.

In some embodiments, the method includes receiving, by the SF, a set identifier from the NFS instance, and storing, by the SF, the context data index and the set identifier.

In some embodiments, the method includes sending, by an NFS instance, a discovery request to a network function repository function (NRF) instructing the NRF to identify a peer NFS instance, and receiving, by the NFS instance, a target identifier from the NRF, wherein the target identifier identifies the peer NFS instance. The discovery request and response may be illustrated, for example, by

steps

401 and 402 in example embodiment 2.

In some embodiments, the method includes sending, by the NFS instance, a message to the SF, wherein the message includes a destination identifier, a route ID, and a UE identifier that identifies the context data.

In some embodiments, the method includes forwarding, by the SF, the message to a second SF based on the target identifier.

In some embodiments, the method includes receiving, by the NFS instance, a response message including a second route ID identifying the peer NFS instance and a second SF, and sending, by the NFS instance, a subsequent message to the SF, wherein the message includes the second route ID, wherein the second route ID indicates the SF to forward the subsequent message to the second SF. This may be shown, for example, in

step

408 and 409 of example embodiment 2.

In some embodiments, the method includes the SF receiving a release message from the NFS instance, and the SF removing the route ID and NFS identification information. This can be illustrated, for example, by

step

504 and 505 of example embodiment 3.

Fig. 10 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. The wireless communication system 1000 may include one or more Base Stations (BSs) 1005a, 1005b, one or

more wireless devices

1010a, 1010b, 1010c, 1010d, and a core network 1025. Base stations 1005a, 1005b may provide wireless service to

wireless devices

1010a, 1010b, 1010c, and 1010d in one or more wireless sectors. In some embodiments, base stations 1005a, 1005b include directional antennas to generate two or more directional beams to provide wireless coverage in different sectors.

The core network 1025 may communicate with one or more base stations 1005a, 1005 b. The core network 1025 provides connectivity to other wireless and wireline communication systems. The core network may include one or more service subscription databases to store information related to subscribed

wireless devices

1010a, 1010b, 1010c, and 1010 d. The first base station 1005a may provide wireless services based on a first radio access technology, and the second base station 1005b may provide wireless services based on a second radio access technology. Depending on the deployment scenario, base stations 1005a and 1005b may be co-located or may be installed separately in the field.

Wireless devices

1010a, 1010b, 1010c, and 1010d 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. 11 is a block diagram representation of a portion of a hardware platform. The hardware platform 1105, such as a network device or base station or wireless device (or UE), may include processor electronics 1110, such as a microprocessor, that processor electronics 1110 implements one or more of the techniques presented in this document. Hardware platform 1105 may include transceiver electronics 1115 to transmit and/or receive wired or wireless signals over one or more communication interfaces (e.g., antenna 1120 or a wired interface). The hardware platform 1105 may implement other communication interfaces using defined protocols for sending and receiving data. Hardware platform 1105 may include one or more memories (not explicitly shown) configured to store information such as data and/or instructions. In some implementations, the processor electronics 1110 can include at least a portion of the transceiver electronics 1115. In some embodiments, at least some of the disclosed techniques, modules, or functions are implemented using a hardware platform 1105. Various functions described herein, e.g., SF, NFS, etc., may be implemented on hardware platform 1105.

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 technology of the disclosure 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 techniques of this disclosure are not limited by the claims below.

The structures and their structural equivalents disclosed in this document, or combinations of one or more of them, can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware. The disclosed 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 standard 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 document in a document system. A program can be stored in a portion of a document that contains other programs or data (e.g., one or more scripts stored in a markup language document), in a single document dedicated to the program in question, or in multiple coordinated documents (e.g., documents 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 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., magneto-optical disks, or optical disks. However, a computer need not have such a device. 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, such as internal hard disks or removable disks; a magneto-optical disk; 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. Furthermore, 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 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, comprising:

generating a context data index of context data associated with the terminal; and

sending the context data index to a service framework, SF, wherein the SF is configured to store a second mapping between the context data index and a route identifier, and a first mapping between an NFS instance identifier identifying a network service function, NFS, instance and the route identifier, the route identifier corresponding to the context data index.

2. The method of claim 1, wherein the context data index is stored at an Unstructured Data Storage Function (UDSF) and the SF.

3. The method of claim 1, wherein the generating is performed by one of an NFS instance or a UDSF.

4. The method of claim 2, further comprising:

sending, by an NFS instance, a request to the UDSF; and

receiving, by the NFS instance, context data and a context data index from the UDSF.

5. The method of claim 1, further comprising:

sending, by the SF to the NFS instance, a routing identifier identifying the NFS instance.

6. The method of claim 5, wherein the routing identifier is included in the context data.

7. The method of claim 5, further comprising:

transmitting, by the NFS instance, at least one of the routing identifier and an NFS instance identifier that identifies the NFS instance to the SF.

8. The method of claim 1, wherein one of an NFS instance, UDSF, or SF generates a set identifier that identifies a set of NFS instances within a cell, wherein the cell includes one or more sets of NFS instances.

9. The method of claim 8, wherein the context data index and the set identifier uniquely identify context data within the cell.

10. The method of claim 8, further comprising:

receiving, by the NFS instance, a set identifier from the UDSF.

11. The method of claim 8, further comprising:

sending, by the NFS instance, the set identifier to the SF, wherein the SF is configured to store the context data index and the set identifier.

12. The method of claim 1, further comprising:

sending, by the NFS instance, a discovery request to a network function repository function (NRF) indicating that the NRF identifies a peer NFS instance; and

receiving, by the NFS instance, a target identifier from the NRF, wherein the target identifier identifies the peer NFS instance.

13. The method of claim 12, wherein the target identifier identifies a set identifier for the peer NFS instance and a second SF.

14. The method of claim 12, wherein the target identifier identifies a second SF and a peer NFS instance identifier that identifies the peer NFS instance.

15. The method of claim 12, further comprising:

sending, by the NFS instance, a message to the SF, the message including a target identifier, a routing identifier, and UE identification information.

16. The method of claim 15, wherein the SF is configured to forward the message to a second SF based on the target identifier.

17. The method of claim 16, further comprising:

receiving, by the NFS instance, a response message including a second routing identifier identifying the peer NFS instance and the second SF; and

sending, by the NFS instance, a subsequent message to the SF, wherein the message includes a second routing identifier, wherein the second routing identifier indicates to the SF to forward the subsequent message to the second SF.

18. The method of claim 1, further comprising:

releasing, by an NFS instance, the routing identifier and the NFS instance identifier; and

sending, by the NFS instance, the route identifier to a UDSF.

19. The method of claim 18, further comprising:

sending, by the NFS instance, a release message to the SF instructing the SF to remove the routing identifier and an NFS instance identifier that identifies the NFS instance.

20. A method for wireless communication, comprising:

receiving a context data index and NFS identification information identifying a Network Function Service (NFS) instance;

generating a unique route ID corresponding to the context data index; and

storing a first mapping between the context data index and the route ID and a second mapping between the route ID and the NFS identification information.

21. The method of claim 20, further comprising:

releasing the second mapping upon receiving a request from a service framework SF.

22. The method of claim 20, wherein the context data index identifies context data.

23. The method of claim 22, wherein the context data index is stored at unstructured data storage functions UDSF and SF.

24. The method of claim 20, further comprising:

sending, by the NFS instance, a request to a UDSF; and

receiving, by the NFS instance, context data from the UDSF, the context data including the context data index and the route ID.

25. The method of claim 20, further comprising:

receiving a request message from a SF, the request message indicating a request for the route ID; and

sending, by the SF, the route ID to an NFS instance.

26. The method of claim 20, wherein one of an NFS instance, UDSF or SF generates a set identifier that identifies a set of NFS instances within a cell, wherein the cell includes one or more sets of NFS instances.

27. The method of claim 26, wherein the context data index and the set identifier uniquely identify context data within the cell.

28. The method of claim 26, further comprising:

receiving, by the NFS instance, a set identifier from the UDSF.

29. The method of claim 26, further comprising:

receiving, by the SF, a set identifier from the NFS instance; and

storing, by the SF, the context data index and the set identifier.

30. The method of claim 20, further comprising:

31. The method of claim 30, wherein the target identifier identifies a set identifier of the peer NFS instance and a second SF.

32. The method of claim 30, wherein the target identifier identifies a second SF and a peer NFS instance identifier that identifies the peer NFS instance.

33. The method of claim 30, further comprising:

sending, by the NFS instance, a message to a SF, the message including a destination identifier, a route ID, and a UE identifier that identifies the context data.

34. The method of claim 30, further comprising:

forwarding, by the SF, the message to a second SF based on the target identifier.

35. The method of claim 34, further comprising:

receiving, by the NFS instance, a response message including a second route ID identifying the peer NFS instance and the second SF; and

sending, by the NFS instance, a subsequent message to the SF, wherein the message includes the second route ID, wherein the second route ID indicates that the SF forwards the subsequent message to the second SF.

36. The method of claim 20, further comprising:

receiving, by an SF, a release message from the NFS instance; and

removing, by the SF, the routing ID and the NFS identification information.

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

38. 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 one of claims 1 to 36.