CN116158067A - 用于间接通信的网络节点和其中的方法 - Google Patents

用于间接通信的网络节点和其中的方法 Download PDF

Info

Publication number
CN116158067A
CN116158067A CN202080104373.7A CN202080104373A CN116158067A CN 116158067 A CN116158067 A CN 116158067A CN 202080104373 A CN202080104373 A CN 202080104373A CN 116158067 A CN116158067 A CN 116158067A
Authority
CN
China
Prior art keywords
request
scp
response
header
apiroot
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080104373.7A
Other languages
English (en)
Inventor
陆赟杰
杨涌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Priority to CN202310843293.9A priority Critical patent/CN116647565A/zh
Publication of CN116158067A publication Critical patent/CN116158067A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本公开提供了一种在实现服务通信代理SCP功能的网络节点中的方法(100)。该方法(100)包括：从第一网络功能NF接收(110)去往第二NF的请求，其中，所述请求包括关于所述第二NF的信息；将该请求重定向(120)到第三NF，其中，重定向的请求包括关于第三NF的信息；以及向第一NF发送(130)响应，其中，所述响应包括关于所述第三NF的信息。

Description

用于间接通信的网络节点和其中的方法
技术领域
本公开涉及通信技术，并且更具体地，涉及用于间接通信的网络和其中的方法。
背景技术
在版本16(Rel-16)中，第三代合作伙伴计划(3GPP)已经进一步拓宽了网络功能(NF)集概念的使用，以适用于第五代(5G)核心中的所有类型的NF。
在Rel-16中，作为网络功能服务框架的一部分，“间接通信”在3GPP技术规范(TS)23.501，V16.4.0中的第7.1.1节中进行了定义，其全部内容通过引用并入本文。NF服务可以在NF服务消费者(或被称为NF消费者)和NF服务产生者(或被称为NF产生者)之间直接通信，或经由服务通信代理(SCP)间接通信。
如TS 23.501中的第5.21.3.1节中所规定的，可以在NF集中部署若干个NF实例，以作为NF实例集一起提供分布、冗余和可扩展性。在这种情况下，可以在失败、负载均衡或负载重新均衡的情况下将NF替换为同一NF集内的备选NF。这适用于服务操作和通知传递两者。
因此，例如当原始NF失败、过载等时，服务(或通知)可以继续在备选NF上。重新选择可以由NF消费者(或NF产生者)或SCP(用于间接通信)来执行。
TS 23.501中的表6.3.1.0-1(再现为以下的表1)定义了NF服务消费者和SCP的取决于由NF服务产生者提供的绑定指示的选择和重新选择行为。
表1：绑定、选择和重新选择
Figure BDA0004113518690000021
3GPP TS 29.500，V16.3.0(其通过引用整体并入本文)规定了在间接通信的情况下处理应用编程接(API)根(apiRoot)的NF和SCP行为。
TS 29.500中的第6.10.2.4节规定了用于间接通信的伪首部设置。具体地，对于有或没有委派发现的间接通信，当向SCP发送请求时，超文本传输协议(HTTP)客户端应将伪首部设置如下：
-“：scheme”被设置为“http”或“https”；
-“：authority”被设置为SCP的完全限定域名(FQDN)或互联网协议(IP)地址(如果方案是“http”)，或被设置为SCP的FQDN(如果方案是“https”)；
-“：path”包括SCP的可选的部署特定的字符串、以及不包括目标统一资源标识符(URI)的可选的部署特定的字符串的目标URI的路径和查询组成部分。
发送通知或回调请求的HTTP客户端无法知道回调URI是否包含任何部署特定的字符串。因此，它的行为应假定回调(即，目标)URI中不存在部署特定的字符串。
另外，对于HTTP客户端可以缓存响应的HTTP请求(例如，GET请求)，HTTP客户端应包括缓存密钥(ck)查询参数，该ck查询参数被设置为与目标NF绑定的实现特定的值。
如果可用，HTTP客户端应在3gpp-Sbi-Target-apiRoot首部中包括目标资源的授权服务器的apiRoot(包括目标URI的可选的部署特定的字符串)。
当向HTTP服务器转发请求时，SCP应将SCP的在传入请求的请求URI中接收到的apiRoot替换为目标NF服务实例的apiRoot。如果在该请求中接收到3gpp-Sbi-Target-apiRoot首部，则如果SCP不(重新)选择不同的HTTP服务器，SCP应将3gpp-Sbi-Target-apiRoot首部用作目标NF服务实例的apiRoot，并且无论如何应将其从转发的请求中移除。SCP应如第6.1节中所规定地设置伪首部，并添加以下内容：
-SCP应将“：authority”HTTP/2伪首部字段修改为目标NF服务实例的FQDN。
-SCP应移除“：path”HTTP/2伪首部中的任何可选的部署特定的字符串，并添加目标URI的任何可选的部署特定的字符串；
-如果在该请求中接收到缓存密钥查询参数，则SCP应移除该参数。
在示例中，对于没有委派发现的间接通信，如果NF服务消费者需要将请求“POSThttps：//example.com/a/b/c/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”发送给NF服务产生者(由FQDN“example.com”表示，并且其中“a/b/c”是从NF发现中得出的NF服务产生者的apiPrefix)：
-NF服务消费者应向SCP发送请求“POST https：//scp.com/1/2/3/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”(其中“1/2/3”是SCP的“apiPrefix”)，具有被设置为“https.：//example.com/a/b/c”的“3gpp-sbi-target-apiRoot”首部。
-SCP应向NF服务产生者发送请求“POST https：//example.com/a/b/c/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”，不具有任何“3gpp-sbi-target-apiRoot”首部。
在另一示例中，对于间接通信，如果NF服务产生者需要将通知请求“POSThttps：//example.com/a/b/c/notification”发送给NF服务消费者(由FQDN“example.com”(即，回调URI的主机部分)表示)，则：
-NF服务产生者应向SCP发送请求“POST https：//scp.com/1/2/3/a/b/c/notification”(其中“1/2/3”是SCP的“apiPrefix”)，具有被设置为“https：//example.com”的“3gpp-sbi-target-apiRoot”首部。
-SCP应向NF服务产生者发送请求“POST https：//example.com/a/b/c/notification”，不具有任何“3gpp-sbi-target-apiRoot”首部。
TS29.500中的第6.10.2.5节规定了3gpp-Sbi-Target-apiRoot首部设置。对于有或没有委派发现的间接通信，如果可用，HTTP客户端应在它发送给SCP的请求中包括被设置为目标资源的授权服务器的apiRoot的3gpp-Sbi-Target-apiRoot首部。具体地：
-对于没有委派发现的间接通信，如果NF服务消费者确实已经选择了特定的NF服务实例，发送给SCP以创建资源的服务请求应包括被设置为NF服务产生者的所选NF服务实例的apiRoot的3gpp-Sbi-Target-apiRoot首部；
-在已经创建资源之后，发送给SCP并以该资源为目标的后续服务请求应包括被设置为先前从NF服务产生者接收到的apiRoot的3gpp-Sbi-Target-apiRoot首部；
-经由SCP发送的通知或回调应包括通知或回调URI的apiRoot(即，“http”或“https”方案，固定的字符串“：//”和授权(主机和可选端口))。
当向HTTP服务器转发该请求时，SCP应如TS29.500中的第6.10.2.4节中所规定地设置伪首部。
发明内容
当NF消费者向NF产生者发送初始请求以在NF产生者上创建资源时，例如，当接入和移动性管理功能(AMF)请求在会话管理功能(SMF)上创建协议数据单元(PDU)会话管理(SM)上下文时，将在201创建的HTTP响应中的“location(位置)”首部中返回新创建的资源的绝对URI(包括托管该资源的HTTP服务器的API根)。NF消费者然后使用该URI对该资源进行后续操作。类似地，NF产生者可以在(隐式或显式地)触发对该通知的订阅的先前服务操作中从NF消费者获取通知URI。
在间接通信中，当原始NF接收者已经失败或过载或任何其他类似情况时，SCP可以重新选择另一NF实例作为新的NF接收者，或者后续请求可以由原始NF接收者显式地重定向到作为新NF接收者的另一NF实例，用于负载控制或重新均衡。在这些场景中，SCP在转发给新NF接收者的请求中使用新NF接收者的apiRoot。本文中所使用的“NF发送者”在服务操作的情况下可以指NF消费者，或在通知的情况下可以指NF产生者。本文中所使用的“NF接收者”在服务操作的情况下可以指NF产生者，或在通知的情况下可以指NF消费者。
仅在用于资源创建的201Created中或仅在仅由SCP用于重新选择场景的307/308重定向响应中支持具有URI的“位置”首部。新的apiRoot仅被SCP知道，而不被NF发送者知道。对于通知，回调URI由消息主体来承载，并仅可以由订阅者显式地更新。因此，将不向NF发送者发送新NF接收者的URI，不知道新NF接收者的apiRootNF的发送者可以仍然使用原始NF接收者的apiRoot进行后续请求或通知。然后，无状态的SCP将需要再次执行重新选择，这将是完全不必要的。更糟糕的是，如果SCP重新选择不同于先前选择的NF接收者的NF接收者，则该资源可能被再次恢复，这将导致资源浪费和冲突。
本公开的目的是提供能够解决或减轻上述问题中的至少一个问题的用于间接通信的网络节点和其中的方法。
根据本公开的第一方面，提供了一种在实现SCP功能的网络节点中的方法。该方法包括：从第一NF接收去往第二NF的请求，该请求包括关于第二NF的信息；将请求重定向到第三NF，重定向的请求包括关于第三NF的信息；以及向第一NF发送响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在重定向的请求中的URI、或在响应中的首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，重定向的操作可以包括响应于与第二NF相关联的失败、负载均衡或负载重新均衡而重新选择第三NF作为请求的接收者，或者可以响应于来自第二NF的指示重定向到第三NF的指示。
在实施例中，重新选择的操作可以包括向NF存储库功能(NRF)执行发现，和/或可以基于与第二NF相关联的绑定指示。该指示还可以指示第三NF的API根。
在实施例中，第一NF或第二NF可以是HTTP服务器、HTTP客户端、NF服务产生者或NF服务消费者之一。
根据本公开的第二方面，提供了一种第一NF中的方法。该方法包括：向SCP发送去往第二NF的请求，该请求包括关于第二NF的信息；以及从SCP或经由SCP从该请求被重定向到的第三NF接收响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在响应中的URI或首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，该方法还可以包括：向SCP发送去往第三NF的另一请求。该另一请求可以包括关于第三NF的信息。
根据本公开的第三方面，提供了一种第三NF中的方法。该方法包括：确定经由SCP从第一NF到第二NF的请求已经被重定向到第三NF；以及经由SCP向第一NF发送响应，该响应包括具有第三NF的API根的URI。
根据本公开的第四方面，提供了一种网络节点。该网络节点包括通信接口、处理器和存储器。该存储器存储可由处理器执行的指令，由此该网络节点可操作以在实现SCP功能时执行根据上述第一方面所述的方法；或在实现第一NF时，执行根据上述第二方面所述的方法；或在实现第三NF时，执行根据上述第三方面所述的方法。
根据本公开的第五方面，提供了一种计算机可读存储介质。该计算机可读存储介质上存储有计算机可读指令。该计算机可读指令在由网络节点的处理器执行时配置网络节点以：在实现SCP功能时，执行根据上述第一方面所述的方法；或在实现第一NF时，执行根据上述第二方面所述的方法；或在实现第三NF时，执行根据上述第三方面所述的方法。
通过本公开的实施例，在将从第一NF接收并去往第二NF的请求重定向到第三NF之后，SCP可以在要发送给第一NF的响应中包括关于第三NF的信息(例如，第三NF的apiRoot)。以这种方式，可以向第一NF通知该信息，并将该消息用于后续服务操作或通知，使得SCP针对后续服务操作或通知不需要再次执行重定向或重新选择，否则会造成资源浪费和冲突。
附图说明
根据以下参考附图对实施例的描述，以上及其他目的、特征和优点将更为明显，在附图中：
图1是示出了根据本公开的实施例的在SCP中的方法的流程图；
图2是示出了根据本公开的实施例的在第一NF中的方法的流程图；
图3是示出了根据本公开的另一实施例的在第三NF中的方法的流程图；
图4是示出了根据本公开的实施例的用于间接通信的示例性过程的序列图；
图5是示出了根据本公开的另一实施例的用于间接通信的示例性过程的序列图；
图6是根据本公开的实施例的网络节点的框图；
图7是根据本公开的实施例的网络节点的框图；
图8是根据本公开的实施例的网络节点的框图；以及
图9是根据本公开的另一实施例的网络节点的框图。
具体实施方式
在本公开中，网络功能或NF可以被实现为专用硬件上的网络元件，或者被实现为在专用硬件上运行的软件实例，或者被实现为在合适的平台上(例如，在云基础设施上)实例化的虚拟化功能。
说明书中对“一个实施例”、“实施例”、“示例实施例”等的引用指示所描述的实施例可以包括特定特征、结构或特性，但是不一定每个实施例都包括该特定特征、结构或特性。此外，这些短语不必指相同实施例。此外，当结合实施例描述具体特征、结构或特性时，应认为结合其他实施例(不管是否是显式描述的)来实现这种特征、结构或特性是在本领域技术人员的知识内的。
应理解，尽管术语“第一”和“第二”等可以在本文中用于描述各种元素，但是这些元素不应受这些术语的限制。这些术语仅用来将元件彼此区分。例如，不脱离示例实施例的范围，第一元件可以被称为第二元件，并且类似地，第二元件可以被称为第一元件。如本文所使用的，词语“和/或”包括一个或多个相关列出词语的任何和所有组合。
本文使用的术语仅仅用于描述特定实施例的目的，而不旨在限制示例实施例。如本文使用的，单数形式“一”，“一个”和“所述”意在还包括复数形式，除非上下文明确地给出相反的指示。将进一步理解的是，当在本文中使用时，术语“包括(comprises)”“包括(comprising)”、“具有(has)”、“具有(having)”、“包括(includes)”和/或“包括(including)”指明所陈述的特征、元素和/或组件等的存在，但不排除存在或添加一个或多个其它特征、元素、组件和/或其组合。
在下面的描述和权利要求中，除非另外定义，否则本文中所使用的所有技术和科学术语具有与本公开所属领域的普通技术人员通常理解的含义相同的含义。
图1是示出了根据本公开的实施例的方法100的流程图。方法100可以在SCP或实现SCP功能的网络节点处执行。
在框110处，从第一NF(例如，NF发送者或HTTP客户端)接收请求。该请求发往第二NF(例如，NF接收者或HTTP服务器)，并包括关于第二NF的信息(例如，第二NF的apiRoot)。
这里，该请求可以是更新第二NF处的资源的请求或通知请求。
在示例中，该请求可以包含具有SCP的API根的URI。第二NF的apiRoot可以在3gpp-Sbi-Target-apiRoot首部中承载。
例如，该请求可以是“POST https：//scp.com/1/2/3/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”(其中“1/2/3”是SCP的“apiPrefix”)，具有被设置为第二NF的apiRoot(例如“https：//example.com/a/b/c”)的“3gpp-sbi-target-apiRoot”首部。这里，“apiRoot”是指“方案”、“授权”和“apiPrefix”的组合。
在框120处，该请求被重定向到第三NF(例如，另一NF接收者或HTTP服务器)。重定向的请求包括关于第三NF的信息(例如，第三NF的apiRoot)。第三NF的apiRoot可以在重定向的请求中的URI中承载。参考上述示例，重定向的请求可以是例如不具有任何“3gpp-sbi-target-apiRoot”首部的“POST https：//example.com/d/e/f/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”，其中“https：//example.com/d/e/f”是第三NF的apiRoot。
在框120中，可以响应于与第二NF相关联的失败、负载均衡或负载重新均衡或任何其他类似情况而重新选择第三NF作为该请求的接收者。这里，SCP可以通过向NRF执行发现来重新选择第三NF。可以基于与第二NF相关联的绑定指示来执行重新选择。
备选地，可以响应于来自第二NF的指示重定向到第三NF的指示来执行框120中的重定向。该指示还可以指示第三NF的apiRoot。例如，该指示可以是或者可以在308重定向响应中承载。
在框130处，向第一NF发送响应。该响应包括关于第三NF的信息(例如，第三NF的apiRoot)。第三NF的apiRoot可以在该响应中的首部(例如，3gpp-Sbi-Target-apiRoot首部)中承载。在上述示例中，该响应可以包含被设置为“https：//example.com/d/e/f”的“3gpp-sbi-target-apiRoot”首部。备选地，第三NF的apiRoot可以在该响应的JavaScript对象表示法(JSON)主体中的属性中的URI来承载。SCP可以从第三NF接收该响应并向第一NF转发该响应。
图2是示出了根据本公开的实施例的方法200的流程图。方法200可以在第一NF(例如，NF发送者或HTTP客户端)或实现第一NF的网络节点处执行。
在框210处，向SCP发送请求。该请求发往第二NF(例如，NF接收者或HTTP服务器)，并包括关于第二NF的信息(例如，第二NF的apiRoot)。
这里，该请求可以是更新第二NF处的资源的请求或通知请求。
在示例中，该请求可以包含具有SCP的API根的URI。第二NF的apiRoot可以在3gpp-Sbi-Target-apiRoot首部中承载。例如，该请求可以是“POST https：//scp.com/1/2/3/nsmf-pdusession/vl/sm-contexts/{smContextRef}/modify”(其中“1/2/3”是SCP的“apiPrefix”)，具有被设置为第二NF的apiRoot(例如“https：//example.com/a/b/c”)的“3gpp-sbi-target-apiRoot”首部。
在框220处，从SCP或经由SCP从该请求被重定向到的第三NF(例如，另一NF接收者或HTTP服务器)接收响应。该响应包括关于第三NF的信息(例如，第三NF的apiRoot)。
在示例中，第三NF的apiRoot可以在该响应中的首部(例如，3gpp-Sbi-Target-apiRoot首部)中承载。在上述示例中，该响应可以包含被设置为第三NF的apiRoot(例如“https：//example.com/d/e/f”)的“3gpp-sbi-target-apiRoot”首部。备选地，第三NF的apiRoot可以在该响应的JSON主体中的属性中的URI中承载。
然后，第一NF(被通知第三NF的信息)知道该请求已经被重定向到第三NF，并且可以在后续请求中使用该信息。在示例中，第一NF可以向SCP发送发往第三NF的另一请求。该另一请求包括关于第三NF的信息(例如，第三NF的apiRoot)。例如，该另一请求可以例如是：https：//scp.com/1/2/3/nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify”，具有被设置为第三NF的apiRoot(例如“https：//example.com/d/e/f”)的“3gpp-sbi-target-apiRoot”首部。
图3是示出了根据本公开的实施例的方法300的流程图。方法300可以在第三NF(例如，NF接收者或HTTP服务器)或实现第三NF的网络节点处执行。
在框310处，确定经由SCP从第一NF(例如，NF发送者或HTTP客户端)到第二NF(例如，NF接收者或HTTP服务器)的请求例如由于SCP的重新选择或第二NF的重定向而已经被重定向到第三NF。
在框320处，经由SCP向第一NF发送响应。该响应包括具有第三NF的apiRoot的URI。当第三NF知道存在请求重定向或资源重定位(即，资源从后端恢复)时，它可以在该响应的JSON主体中的属性中包括具有第三NF的apiRoot的URI。
下面将描述本公开的一些示例性实施例。
如果选择或重新选择了新的HTTP服务器并且在该响应中不包括位置首部，则如TS29.500中所规定的3gpp-Sbi-Target-apiRoot首部可以由SCP用于指示目标URI的apiRoot。TS 29.500的表5.2.3.2.1-1中“3gpp-Sbi-Target-apiRoot”首部的定义可以被扩展以支持上述特征，如下面的表2所示。
表2：强制性HTTP定制首部
Figure BDA0004113518690000121
当SCP选择或重新选择了新的HTTP服务器来路由该请求并且HTTP响应中不包括位置HTTP首部时，如TS 29.500中所规定的3gpp-Sbi-Target-apiRoot首部可以在发送给HTTP客户端的响应中包含所选或所更改的目标URI的apiRoot。
如果HTTP响应(例如，对创建的资源的后续服务请求的HTTP响应)中不包括“位置”首部，则当向作为HTTP客户端的NF转发HTTP响应时，SCP应包括值被设置为目标HTTP服务器的apiRoot的“3gpp-Sbi-Target-apiRoot”首部，除非SCP在将请求从作为HTTP客户端的NF转发给作为HTTP服务器的NF时未更改目标URI。作为HTTP客户端的NF可以将该请求中使用的本地存储的URI(例如，资源URI或通知回调URI)更新为在HTTP响应中接收到的目标apiRoot，从而向更新后的目标URI发送后续请求。
下面将参考图4至图5中所示的说明性示例进一步说明上述方法100至300。
图4是示出了根据本公开的实施例的用于间接通信的示例性过程的序列图。在该示例中，请求由于SCP重新选择NF接收者而被重定向。
如图所示，在4.1处，作为NF发送者(也是NF消费者和HTTP客户端)的AMF在这种情况下向SCP发送更新请求。在这种情况下，该更新请求去往作为NF接收者(也是NF产生者和HTTP服务器)的SMF(被表示为SMF1)。该更新请求可以是例如用于更新已经在SMF1处创建的PDU SM上下文的更新SM上下文请求。该更新SM上下文请求可以包含具有被设置为{apiRootofSMF1}的“3gpp-sbi-target-apiRoot”首部的URI“{apiRootofSCP}/nsmf-pdusession/vl/sm-contexts/{smContextRef}”。在4.2处，SCP向SMF1转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF1}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。然而，例如由于SMF1的失败，4.2处的转发失败。在4.3处，SCP向NRF执行NF发现以进行NF接收者重新选择(例如，基于与SMF１相关联的绑定指示)。在4.4处，SCP重新选择另一SMF(被表示为SMF2)作为新的NF接收者，并从自NRF获取的NF配置文件中获得SMF2的apiRoot。在4.5处，SCP向SMF2转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF2}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。在4.6处，SCP从SMF2接收更新响应(例如，更新SM上下文响应)。在4.7处，SCP向AMF转发该更新响应。这里转发的响应可以包括被设置为{apiRootofSMF2}的“3gpp-sbi-target-apiRoot”首部。
在4.8处，AMF向SCP发送另一更新请求(例如，更新SM上下文请求)。该更新SM上下文请求可以包含具有被设置为{apiRoot of SMF2}的“3gpp-sbi-target-apiRoot”首部的URI“{apiRootofSCP}/nsmf-pdusession/v1/sm-contexts/{smContextRef}”。在4.9处，SCP向SMF2转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF2}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。在4.10处，SCP从SMF2接收更新响应(例如，更新SM上下文响应)。在4.11处，SCP向AMF转发该更新响应。
图5是示出了根据本公开的实施例的用于间接通信的示例性过程的序列图。在该示例中，请求由于NF接收者的重定向而被重定向。
如图所示，在5.1处，作为NF发送者(也是NF消费者和HTTP客户端)的AMF在这种情况下向SCP发送更新请求。在这种情况下，该更新请求去往作为NF接收者(也是NF产生者和HTTP服务器)的SMF(被表示为SMF1)。该更新请求可以是例如用于更新已经在SMF1处创建的PDU SM上下文的更新SM上下文请求。该更新SM上下文请求可以包含具有被设置为{apiRootof SMF1}的“3gpp-sbi-target-apiRoot”首部的URI“{apiRootofSCP}/nsmf-pdusession/vl/sm-contexts/{smContextRef}”。在5.2处，SCP向SMF1转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF1}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。在5.3处，SMF1决定将该请求重定向到作为新NF接收者的另一SMF(被表示为SMF2)。在5.4处，SMF1向SCP发送包含指示{apiRootofSMF2}/nsmf-pdusession/v1/sm-contexts/{smContextRef}的位置首部的308永久移动响应。在5.5处，SCP基于在5.3处接收到的响应向SMF2转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF2}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。在5.6处，SCP从SMF2接收更新响应(例如，更新SM上下文响应)。在5.7处，SCP向AMF转发该更新响应。这里转发的响应可以包括被设置为{apiRoot of SMF2}的“3gpp-sbi-target-apiRoot”首部。
在5.8处，AMF向SCP发送另一更新请求(例如，更新SM上下文请求)。该更新SM上下文请求可以包含具有被设置为{apiRoot of SMF2}的“3gpp-sbi-target-apiRoot”首部的URI“{apiRootofSCP}/nsmf-pdusession/vl/sm-contexts/{smContextRef}”。在5.9处，SCP向SMF2转发该更新请求。这里转发的请求可以是例如：{apiRoot of SMF2}/nsmf-pdusession/v1/sm-contexts/{smContextRef}。在5.10处，SCP从SMF2接收更新响应(例如，更新SM上下文响应)。在5.11处，SCP向AMF转发该更新响应。
对应于如上所述的方法100，提供了网络节点。图6是根据本公开的实施例的网络节点600的框图。网络节点600可以被配置为实现SCP功能。
如图6中所示，网络节点600包括接收单元610，该接收单元610被配置为从第一NF接收发往第二NF的请求，该请求包括第二NF的信息。网络节点600还包括重定向单元620，该重定向单元620被配置为将该请求重定向到第三NF，重定向的请求包括关于第三NF的信息。网络节点600还包括发送单元630，该发送单元630被配置为向第一NF发送响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在重定向的请求中的URI、或在响应中的首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，重定向单元620可以被配置为响应于与第二NF相关联的失败、负载均衡或负载重新均衡而重新选择第三NF作为该请求的接收者，或者可以被配置为响应于来自第二NF的指示重定向到第三NF的指示而将该请求重定向到第三NF。
在实施例中，重定向单元620可以被配置为通过向NRF执行发现来重新选择第三NF，和/或基于与第二NF相关联的绑定指示来重新选择第三NF。该指示还可以指示第三NF的API根。
在实施例中，第一NF或第二NF可以是HTTP服务器、HTTP客户端、NF服务产生者或NF服务消费者之一。
单元610至630可以例如通过以下各项中的一项或多项实现为纯硬件解决方案或软件和硬件的组合：处理器或微处理器和适合软件以及用于存储软件的存储器、可编程逻辑器件(PLD)或其他电子部件或被配置为执行上述以及例如在图1中示出的动作的处理电路。
对应于如上所述的方法200，提供了网络节点。图7是根据本公开的实施例的网络节点700的框图。网络节点700可以被配置为实现第一NF(例如，NF发送者或HTTP客户端)。
如图7中所示，网络节点700包括发送单元710，该发送单元710被配置为向SCP发送去往第二NF的请求，该请求包括关于第二NF的信息。网络节点700还包括接收单元720，该接收单元720被配置为从SCP或经由SCP从该请求被重定向到的第三NF接收响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在响应中的URI或首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，网络节点700还可以包括发送单元，该发送单元被配置为向SCP发送去往第三NF的另一请求。该另一请求可以包括关于第三NF的信息。
单元710至720可以例如通过以下各项中的一项或多项实现为纯硬件解决方案或软件和硬件的组合：处理器或微处理器和适合软件以及用于存储软件的存储器、可编程逻辑器件(PLD)或其他电子部件或被配置为执行上述以及例如在图2中示出的动作的处理电路。
对应于如上所述的方法300，提供了网络节点。图8是根据本公开的实施例的网络节点800的框图。网络节点800可以被配置为实现第三NF(例如，NF接收者或HTTP服务器)。
如图8中所示，网络节点800包括确定单元810，该确定单元810被配置为确定经由SCP从第一NF到第二NF的请求被重定向到第三NF。网络节点800还包括发送单元820，该发送单元820被配置为经由SCP向第一NF发送响应，该响应包括具有第三NF的API根的URI。
单元810至820可以例如通过以下各项中的一项或多项实现为纯硬件解决方案或软件和硬件的组合：处理器或微处理器和适合软件以及用于存储软件的存储器、可编程逻辑器件(PLD)或其他电子部件或被配置为执行上述以及例如在图3中示出的动作的处理电路。
图9是根据本公开的另一实施例的网络节点900的框图。
网络节点900包括通信接口910、处理器920和存储器930。
存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现SCP功能时执行例如前面结合图1描述的过程的动作。具体地，存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现SCP功能时：从第一NF接收去往第二NF的请求，该请求包括关于第二NF的信息；将请求重定向到第三NF，该重定向的请求包括关于第三NF的信息；以及向第一NF发送响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在重定向的请求中的URI、或在响应中的首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，重定向的操作可以包括响应于与第二NF相关联的失败、负载均衡或负载重新均衡而重新选择第三NF作为请求的接收者，或者可以响应于来自第二NF的指示重定向到第三NF的指示。
在实施例中，重新选择的操作可以包括向NF存储库功能(NRF)执行发现，和/或可以基于与第二NF相关联的绑定指示。该指示还可以指示第三NF的API根。
在实施例中，第一NF或第二NF可以是HTTP服务器、HTTP客户端、NF服务产生者或NF服务消费者之一。
备选地，存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现第一NF时执行例如前面结合图2描述的过程的动作。具体地，存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现第一NF时：向SCP发送去往第二NF的请求，该请求包括关于第二NF的信息；以及从SCP或经由SCP从该请求被重定向到的第三NF接收响应，该响应包括关于第三NF的信息。
在实施例中，该请求可以是更新第二NF处的资源的请求或通知请求。
在实施例中，关于第三NF的信息可以指示第三NF的API根。
在实施例中，第三NF的信息可以在响应中的URI或首部中承载。
在实施例中，该首部可以是3gpp-Sbi-Target-apiRoot首部。
在实施例中，发往第二NF的请求可以包含：具有SCP的API根的URI。关于第二NF的信息可以指示第二NF的API根并且可以在3gpp-Sbi-Target-apiRoot首部中承载。
在实施例中，存储器930还可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现第一NF时：向SCP发送去往第三NF的另一请求。该另一请求可以包括关于第三NF的信息。
备选地，存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现第三NF时执行例如前面结合图3描述的过程的动作。具体地，存储器930可以包含可由处理器920执行的指令，由此网络节点900可操作以在实现第三NF时：确定经由SCP从第一NF到第二NF的请求已经被重定向到第三NF；以及经由SCP向第一NF发送响应，该响应包括具有第三NF的API根的URI。
本公开还提供了非易失性或易失性存储器形式的至少一个计算机程序产品，例如，非暂时性计算机可读存储介质、电可擦除可编程只读存储器(EEPROM)、闪存和硬盘驱动器。计算机程序产品包括计算机程序。计算机程序包括：代码/计算机可读指令，当被处理器920执行时使网络节点900执行例如前面结合图1、图2或图3描述的过程的动作。
计算机程序产品可以被配置为以计算机程序模块构造的计算机程序代码。计算机程序模块可以基本上执行图1、图2或图3中所示的流程的动作。
处理器可以是单个CPU(中央处理单元)，但是还可以包括两个或多于两个处理单元。例如，处理器可以包括通用微处理器；指令集处理器和/或相关芯片集和/或专用微处理器，例如专用集成电路(ASIC)。处理器还可以包括用于高速缓存目的的板载存储器。计算机程序可以在与处理器连接的计算机程序产品中承载。计算机程序产品可以包括存储计算机程序的非瞬时计算机可读存储介质。例如，计算机程序产品可以是闪存、随机存取存储器(RAM)、只读存储器(ROM)或EEPROM，并且上述计算机程序模块在备选实施例中可以分布在存储器形式的不同计算机程序产品上。
以上已经参考其实施例描述了本公开。应当理解，在不脱离本公开的精神和范围的情况下，本领域技术人员可以进行各种修改、替换和添加。因此，本公开的范围不限于上述特定实施例，而是仅由所附权利要求限定。

Claims (19)

1.一种在实现服务通信代理SCP功能的网络节点中的方法(100)，包括：
从第一网络功能NF接收(110)去往第二NF的请求，其中，所述请求包括关于所述第二NF的信息；
将所述请求重定向(120)到第三NF，其中，重定向的请求包括关于所述第三NF的信息；以及
向第一NF发送(130)响应，其中，所述响应包括关于所述第三NF的信息。
2.根据权利要求1所述的方法(100)，其中，所述请求是更新所述第二NF处的资源的请求或通知请求。
3.根据权利要求1或2所述的方法(100)，其中，关于所述第三NF的信息指示所述第三NF的应用编程接口API根。
4.根据权利要求1至3中任一项所述的方法(100)，其中，关于所述第三NF的信息在重定向的请求中的统一资源标识符URI中或在所述响应中的首部中承载。
5.根据权利要求4所述的方法(100)，其中，所述首部是3gpp-Sbi-Target-apiRoot首部。
6.根据权利要求1至5中任一项所述的方法(100)，其中，去往所述第二NF的请求包含：具有所述SCP的API根的URI，并且关于所述第二NF的信息指示所述第二NF的API根并在3gpp-Sbi-Target-apiRoot首部中承载。
7.根据权利要求1至6中任一项所述的方法(100)，其中，所述重定向(120)包括响应于与所述第二NF相关联的失败、负载均衡或负载重新均衡而重新选择所述第三NF作为所述请求的接收者，或者响应于来自所述第二NF的指示重定向到所述第三NF的指示。
8.根据权利要求7所述的方法(100)，其中，
所述重新选择包括向NF存储库功能NRF执行发现，和/或基于与所述第二NF相关联的绑定指示，或
所述指示还指示所述第三NF的API根。
9.根据权利要求1至8中任一项所述的方法(100)，所述第一NF或第二NF是超文本传输协议HTTP服务器、HTTP客户端、NF服务产生者或NF服务消费者之一。
10.一种第一网络功能NF中的方法(200)，包括：
向服务通信代理SCP发送(210)去往第二NF的请求，其中，所述请求包括关于所述第二NF的信息；以及
从所述SCP或经由所述SCP从所述请求被重定向到的第三NF接收(220)响应，其中，所述响应包括关于所述第三NF的信息。
11.根据权利要求10所述的方法(200)，其中，所述请求是更新所述第二NF处的资源的请求或通知请求。
12.根据权利要求10或11所述的方法(200)，其中，关于所述第三NF的信息指示所述第三NF的应用编程接口API根。
13.根据权利要求10至12中任一项所述的方法(200)，其中，关于所述第三NF的信息在所述响应中的统一资源标识符URI中或首部中承载。
14.根据权利要求13所述的方法(200)，其中，所述首部是3gpp-Sbi-Target-apiRoot首部。
15.根据权利要求10所述的方法(200)，其中，去往所述第二NF的请求包含：具有所述SCP的API根的URI，并且关于所述第二NF的信息指示所述第二NF的API根并在3gpp-Sbi-Target-apiRoot首部中承载。
16.根据权利要求11至15中任一项所述的方法(200)，还包括：
向所述SCP发送去往所述第三NF的另一请求，其中，所述另一请求包括关于所述第三NF的信息。
17.一种第三网络功能NF中的方法(300)，包括：
确定(310)经由服务通信代理SCP从第一NF到第二NF的请求已经被重定向到所述第三NF；以及
经由所述SCP向所述第一NF发送(320)响应，其中，所述响应包括具有所述第三NF的应用编程接口API根的统一资源标识符URI。
18.一种网络节点(900)，包括通信接口(910)、处理器(920)和存储器(930)，所述存储器(930)包括能够由所述处理器(920)执行的指令，由此所述网络节点(900)操作用于：在实现服务通信代理SCP功能时，执行根据权利要求1至9中任一项所述的方法；或在实现第一网络功能NF时，执行根据权利要求10至16中任一项所述的方法；或在实现第三网络功能NF时，执行根据权利要求17所述的方法。
19.一种存储有计算机可读指令的计算机可读存储介质，所述计算机可读指令当由网络节点的处理器执行时将所述网络节点配置为：在实现服务通信代理SCP功能时，执行根据权利要求1至9中任一项所述的方法；或在实现第一网络功能NF时，执行根据权利要求10至16中任一项所述的方法；或在实现第三网络功能NF时，执行根据权利要求17所述的方法。
CN202080104373.7A 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法 Pending CN116158067A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310843293.9A CN116647565A (zh) 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN2020107899 2020-08-07
CNPCT/CN2020/107899 2020-08-07
PCT/CN2020/134182 WO2022027887A1 (en) 2020-08-07 2020-12-07 Network nodes and methods therein for indirect communication

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202310843293.9A Division CN116647565A (zh) 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法

Publications (1)

Publication Number Publication Date
CN116158067A true CN116158067A (zh) 2023-05-23

Family

ID=74003660

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202310843293.9A Pending CN116647565A (zh) 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法
CN202080104373.7A Pending CN116158067A (zh) 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202310843293.9A Pending CN116647565A (zh) 2020-08-07 2020-12-07 用于间接通信的网络节点和其中的方法

Country Status (7)

Country Link
US (2) US20230291809A1 (zh)
EP (2) EP4369688A1 (zh)
JP (1) JP7466756B2 (zh)
CN (2) CN116647565A (zh)
AU (1) AU2020462696A1 (zh)
BR (1) BR112023001927A2 (zh)
WO (1) WO2022027887A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024001734A1 (en) * 2022-06-29 2024-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Feature discovery in non-direct subscription scenarios

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10693860B2 (en) * 2017-09-08 2020-06-23 Citrix Systems, Inc. RDP proxy support in presence of RDP server farm with session directory or broker
US11323550B2 (en) * 2020-02-17 2022-05-03 Cisco Technology, Inc. Techniques to send load-share notifications to multiple receivers
EP3886401A1 (en) * 2020-03-27 2021-09-29 Nokia Technologies Oy Method, apparatus, and computer program product for error handling for indirect communications

Also Published As

Publication number Publication date
BR112023001927A2 (pt) 2023-03-28
JP7466756B2 (ja) 2024-04-12
US20240171653A1 (en) 2024-05-23
EP4193585A1 (en) 2023-06-14
CN116647565A (zh) 2023-08-25
US20230291809A1 (en) 2023-09-14
EP4369688A1 (en) 2024-05-15
JP2023537468A (ja) 2023-09-01
EP4193585B1 (en) 2024-05-01
WO2022027887A1 (en) 2022-02-10
AU2020462696A1 (en) 2023-04-20

Similar Documents

Publication Publication Date Title
US20200336554A1 (en) Proxy routing based on path headers
CN112468604B (zh) 域名系统服务器的确定方法、请求处理方法和装置、系统
US11750694B2 (en) CDN-based client messaging
CN114747252A (zh) 用于识别移动网络中适合于边缘疏导和适合于业务导向的业务的方法
CN114503644B (zh) 支持具有tls的间接通信
CN109451804B (zh) cNAP以及由cNAP、sNAP执行的方法
US11202252B2 (en) Inclusion of a message proxy in a service based architecture
JP7450803B2 (ja) 通知配信のためのネットワークノードおよびネットワークノードにおける方法
US20240171653A1 (en) Network nodes and methods therein for indirect communication
US20190037044A1 (en) Content distribution and delivery optimization in a content delivery network (cdn)
WO2022083385A1 (en) Network nodes and methods therein for providing backup network function
US9467377B2 (en) Associating consumer states with interests in a content-centric network
JP2024513850A (ja) エッジ構成サーバ情報処理方法、装置及び通信機器
WO2016062053A1 (zh) 一种实现路由的方法及设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination