CN113271353B - 一种面向卫星的数据缓存终端选择方法和装置 - Google Patents
一种面向卫星的数据缓存终端选择方法和装置 Download PDFInfo
- Publication number
- CN113271353B CN113271353B CN202110525716.3A CN202110525716A CN113271353B CN 113271353 B CN113271353 B CN 113271353B CN 202110525716 A CN202110525716 A CN 202110525716A CN 113271353 B CN113271353 B CN 113271353B
- Authority
- CN
- China
- Prior art keywords
- terminal
- satellite
- service
- popularity
- terminals
- 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.)
- Active
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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/185—Space-based or airborne stations; Stations for satellite systems
- H04B7/1853—Satellite systems for providing telephony service to a mobile station, i.e. mobile satellite service
- H04B7/18532—Arrangements for managing transmission, i.e. for transporting data or a signalling message
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Abstract
本申请实施例提供一种面向卫星的数据缓存终端选择方法和装置,该数据缓存终端选择方法包括:接收第一业务;其中,第一业务为接收的多种业务中的任意一种业务;根据第一业务,计算多个终端中每个终端对应的业务流行度值;根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端;其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。借助于上述技术方案,本申请实施例能够提高转发效率。
Description
技术领域
本申请涉及卫星通信技术领域,具体地涉及一种面向卫星的数据缓存终端选择方法和装置。
背景技术
多元化的视频、图片等内容类应用正在成为主流应用,网络内的内容分发需求越来越强,网络的“以内容为中心”特性日趋明显。所有的业务数据(或者内容类数据)被认为存储在服务器当中,当用户需要请求特定的内容时,通过相应的业务请求(或者内容请求)转发至服务器侧,服务器再回传用户所请求的内容文件从而完成整个内容获取过程。由于每个用户的业务请求和回传业务数据都是相对独立的端到端过程,当同一内容被多个用户进行请求后,会在网络中产生内容重复的流量。
此外,随着内容类流量的增长,相同内容数据的重复传输对资源受限的卫星造成了巨大的负载压力,尤其当一个区域内大量用户在同一时间请求相同的内容数据时,将造成相同内容的重复传输,这给卫星的回程链路和源端服务器造成挑战,引起了资源的浪费,严重影响卫星对其他业务请求的服务质量。
目前,为了解决上述问题,卫星通过流量卸载将业务数据缓存在地面的部分终端上,并且终端之间可通过地面网络进行数据请求和传输,这样一方面降低了卫星回程链路的带宽、负载压力和减少了功率资源的浪费,另一方面离用户更近的内容部署减少了获取延迟,提高用户的服务体验。
但是,在实现本发明的过程中,发明人发现现有技术中存在如下问题:由于地面上用于缓存业务数据的终端的选取是随机的,从而容易引起转发效率比较低的问题。例如,卫星从多个终端中随机选择一个终端作为缓存业务数据的终端,由于该终端发送的数据需要经过很多跳才能到达请求业务数据的终端,从而造成了转发效率比较低的问题。
发明内容
本申请实施例的目的在于提供一种面向卫星的数据缓存终端选择方法和装置,以解决现有技术中存在着的转发效率比较低的问题。
第一方面,本申请实施例公开了一种面向卫星的数据缓存终端选择方法,数据缓存终端选择方法应用于卫星通信系统中的卫星,卫星通信系统包括多个终端和卫星,多个终端处于卫星的覆盖范围内,数据缓存终端选择方法包括:接收第一业务;其中,第一业务为接收的多种业务中的任意一种业务;根据第一业务,计算多个终端中每个终端对应的业务流行度值;根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端;其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。
因此,由于本申请实施例中的目标终端的选取是根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率来进行的,使得目标终端的选取不仅考虑到了地面网络侧倾向于将业务数据缓存在内容流行区域内的终端的需求,也考虑到了卫星侧倾向于选择星地链路信道状态更好的终端进行地面传输的需求,从而相比于现有的终端的选取方法,其不仅可解决转发效率比较低的问题(即其可提高转发效率),还达到了综合考虑地面网络侧和卫星侧的两方面的需求来进行终端的选取的效果。
在一个可能的实施例中,根据第一业务,计算多个终端中每个终端对应的业务流行度值,包括,根据以下公式计算业务流行度值:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示终端m是否请求业务k,M(m,n)表示距终端m的跳数为预设跳数n的终端集合。
在一个可能的实施例中,预设跳数n是根据终端m和多个终端中除终端m之外的其他终端间的网络传输情况来确定的。
在一个可能的实施例中,根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端,包括:根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,建立确定目标终端的问题模型;其中,问题模型用于最大化业务流行度加权下的卫星下行吞吐量;利用拉格朗日对偶算法获取问题模型的最优解,并将最优解对应的终端作为目标终端。
在一个可能的实施例中,利用拉格朗日对偶算法获取问题模型的最优解,包括,通过如下公式获取最优解:
其中,m*表示最优解对应的终端m,wk,m表示终端m对应的业务流行度值,Rk,m表示卫星到终端m的下行吞吐量,α为拉格朗日因子,hm表示卫星和终端m之间的信噪比。
第二方面,本申请实施例公开了一种面向卫星的数据缓存终端选择装置,数据缓存终端选择装置应用于卫星通信系统中的卫星,卫星通信系统包括多个终端和卫星,多个终端处于卫星的覆盖范围内,数据缓存终端选择装置包括:接收模块,用于接收第一业务;其中,第一业务为接收的多种业务中的任意一种业务;计算模块,用于根据第一业务,计算多个终端中每个终端对应的业务流行度值;选取模块,用于根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端;其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。
在一个可能的实施例中,计算模块,具体用于根据以下公式计算业务流行度值:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示终端m是否请求业务k,M(m,n)表示距终端m的跳数为预设跳数n的终端集合。
在一个可能的实施例中,预设跳数n是根据终端m和多个终端中除终端m之外的其他终端间的网络传输情况来确定的。
在一个可能的实施例中,选取模块,具体用于:根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,建立确定目标终端的问题模型;其中,问题模型用于最大化业务流行度加权下的卫星下行吞吐量;利用拉格朗日对偶算法获取问题模型的最优解,并将最优解对应的终端作为目标终端。
在一个可能的实施例中,选取模块,具体用于通过如下公式获取最优解:
其中,m*表示最优解对应的终端m,wk,m表示终端m对应的业务流行度值,Rk,m表示卫星到终端m的下行吞吐量,α为拉格朗日因子,hm表示卫星和终端m之间的信噪比。
第三方面,本申请实施例提供了一种存储介质,该存储介质上存储有计算机程序,该计算机程序被处理器运行时执行第一方面或第一方面的任一可选的实现方式所述的方法。
第四方面,本申请实施例提供了一种电子设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当所述电子设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行第一方面或第一方面的任一可选的实现方式所述的方法。
第五方面,本申请提供一种计算机程序产品,所述计算机程序产品在计算机上运行时,使得计算机执行第一方面或第一方面的任意可能的实现方式中的方法。
为使本申请实施例所要实现的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例提供的一种应用场景的示意图;
图2示出了本申请实施例提供的一种面向卫星的数据缓存终端选择方法的流程图;
图3示出了本申请实施例提供的一种面向卫星的数据缓存终端选择装置的结构框图;
图4示出了本申请实施例提供的一种电子设备的结构框图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本申请的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
目前,在星地网络中进行流量卸载在经济、高效地提升系统性能的同时,也伴随着一些挑战,由于业务数据需求存在地域性差别,即分布在不同地域的用户对业务数据的需求不一样,业务流行度有明显差异。为了更大程度地实现终端间的内容共享,需要选择合适的终端来接收并缓存卫星对地面传输的业务数据。终端间网络(或者地面网络)侧倾向于将业务数据缓存在内容流行区域内的终端上,并且其需要兼顾地面网络的网络拥塞情况,同时,卫星侧倾向于选择星地链路信道状态更好的终端进行地面传输。因此,需要综合考虑地面网络侧和卫星侧的两方面的需求来进行终端的选取。
但是,现有技术中是通过沿途处处缓存(Cache Everything Everywhere,CCE)策略来实现的。由于该CCE策略要求将业务数据存储到返回路径的所有节点上,使得产生的缓存冗余较多,节点缓存内容同质化,而且节点缓存替换操作频繁,增加了节点处理消耗。
以及,为了减少CEE策略的缓存冗余,目前有些研究从网络拓扑和缓存收益等多个方面开展沿路径缓存策略研究,以达到改善网络缓存效率的目的。然而,上述沿路径缓存策略大多未考虑业务流行度,对于考虑业务流行度的研究,没有考虑不同用户分布特征下的网络拥塞差异,同时,也未涉及卫星侧(或者服务提供方)与用户之间的利益平衡。
基于此,本申请实施例巧妙地提出了一种面向卫星的数据缓存终端选择方案,通过接收第一业务,其中,第一业务为接收的多种业务中的任意一种业务,随后根据第一业务,计算多个终端中每个终端对应的业务流行度值,最后根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端;其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。
因此,由于本申请实施例中的目标终端的选取是根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率来进行的,使得目标终端的选取不仅考虑到了地面网络侧倾向于将业务数据缓存在内容流行区域内的终端的需求,也考虑到了卫星侧倾向于选择星地链路信道状态更好的终端进行地面传输的需求,从而相比于现有的终端的选取方法,其不仅可解决转发效率比较低的问题,还达到了综合考虑地面网络侧和卫星侧的两方面的需求来进行终端的选取的效果。
请参见图1,图1示出了本申请实施例提供的一种应用场景的示意图。如图1所示的应用场景包括服务器、卫星和多个终端。其中,服务器和卫星通信连接,以及卫星还与多个终端通信连接(即多个终端处于卫星的覆盖范围内)。
应理解,服务器的具体装置、卫星的具体装置和终端的具体装置均可根据实际需求来进行设置,本申请实施例并不局限于此。
例如,服务器可以为单个服务器,也可以为服务器集群。
再例如,卫星可以为北斗卫星,也可以为GPS卫星等。
再例如,终端可以为手机,也可以为无人车,也可以为无人机等。
还应理解,卫星的工作频段和终端的具体数量等也可根据实际需求来进行设置,本申请实施例并不局限于此。
例如,卫星的工作频段可以为KU频段以及KU频段以上的频段。
为了便于理解本申请实施例,下面通过具体的实施例来进行描述。
具体地,可通过服务器将业务数据上传到卫星,若卫星收到第一业务请求,则卫星可按照本申请实施例中的终端的选取方法来从多个终端中选取目标终端,并可通过卫星下行链路将第一业务请求对应的业务数据下发到目标终端。
此外,由于多个终端之间是互联的,目标终端可通过地面网络分发业务数据,以将业务数据分发到上传第一业务请求的请求终端。例如,在目标终端和请求终端之间具有多跳链路的情况下,业务数据可经由多条链路进行分发。
应理解,数据缓存终端选择方法的具体过程可参见图2的相关描述,在此不再详细描述。
还应理解,虽然本申请实施例是以图1为例来进行描述的,但本领域的技术人员应当理解,还可根据实际需求对图1所示的应用场景进行改进,本申请实施例并不局限于此。
例如,该应用场景还可包括更多地服务器或者卫星。
请参见图2,图2示出了本申请实施例提供的一种面向卫星的数据缓存终端选择方法的流程图。如图2所示的数据缓存终端选择方法应用于卫星通信系统中的卫星,卫星通信系统包括多个终端和卫星,多个终端处于卫星的覆盖范围内,该数据缓存终端选择方法包括:
步骤S210,卫星接收第一业务。其中,第一业务为由卫星接收的多种业务中的任意一种业务。
应理解,第一业务请求的数据可根据实际需求来进行设置,本申请实施例并不局限于此。
例如,第一业务可用于请求视频数据等。
还应理解,第一业务可以是由至少两个终端中每个终端分别发送的。例如,第一终端和第二终端分别向卫星上传第一业务,以请求视频数据。
还应理解,第一业务也可以称为第一业务请求,对应的,多种业务也可以称为多种业务请求等。
这里需要说明的是,为了减少资源消耗,本申请实施例中相同内容的业务数据可通过卫星分配给一个地面的目标终端,即需要选择适当的终端来缓存业务数据(例如,视频数据等),而其他终端则通过地面多跳链路来共享内容。
也就是说,对于同一种业务来说,卫星可将该种业务对应的业务数据分配给一个目标终端,然后其他终端可通过多跳链路来共享内容。
步骤S220,卫星根据第一业务,计算多个终端中每个终端对应的业务流行度值。其中,业务流行度值可用于表示与第一业务相关的业务数据的受欢迎程度。
应理解,业务流行度也可称为内容流行度,本申请实施例并不局限于此。
还应理解,终端也可以称为用户,也可以称为地面终端等。
还应理解,卫星根据第一业务,计算多个终端中每个终端对应的业务流行度值的具体过程可根据实际需求来进行设置,本申请实施例并不局限于此。
可选地,本申请实施例中的地面终端可表示为M={1,2,...,M},并且M个终端可处于卫星的覆盖范围内,以及任意一个终端可通过多跳链路(例如,多跳无线链路)到达其他所有终端。其中,M大于等于2。以及,本申请实施例中的终端的业务需求可包括K种不同的业务需求,即业务需求可用K={1,2,...,K}表示,并且不同的终端可能会对同一业务数据感兴趣。其中,K大于等于2。
以及,为了减少目标终端到请求业务数据的请求终端间的路径长度,对于每种业务对应的业务数据,本申请实施例可选取一个位于内容热点区域(或者业务数据热点区域)内的终端来缓存对应的业务数据。为此,本申请实施例基于请求第一业务的用户数量和这些用户之间的距离(或者拓扑关系)构建了业务流行度的计算公式。其中,本申请实施例中两个终端之间的距离可表示两个终端间的最短路径跳数。
此外,该业务流行度的计算公式为:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示终端m是否请求业务k,M(m,n)表示距终端m的跳数为预设跳数n的终端集合,m和m'均是指终端m。
这里需要说明的是,当终端m越靠近请求第一业务的请求终端,wk,m随之增大,从而本申请实施例中的地面网络更倾向于终端m来缓存与第一业务相关的业务数据。
还应理解,预设跳数n的具体值可根据实际需求来进行设置,本申请实施例并不局限于次。
可选地,若n的取值为最大跳数约束(或者最大跳数),则wk,m为全局流行度,最大跳数也可根据实际需求来进行设置;当n的取值小于最大跳数约束的情况下,若n取值变小,则wk,m为局部流行度,此时n的取值可根据终端m和多个终端中除终端m之外的其他终端间的网络传输情况来确定,从而可在一定程度上缓解网络拥塞。其中,网络传输情况可以是通过网络拥塞情况或者网络流量等来确定的。
例如,在终端m和多个终端中除终端m之外的其他终端间的网络流量(例如,平均网络流量)大于等于预设流量的情况下,则可降低n的取值;在终端m和多个终端中除终端m之外的其他终端间的网络流量小于预设流量的情况下,则可增大n的取值。其中,预设流量的大小可根据实际需求来进行设置。
还应理解,虽然上面是以根据网络传输情况来调整预设跳数n的取值为例来进行描述的,但本领域的技术人员应当理解,还可通过其他的方式来调整预设跳数n的取值,本申请实施例并不局限于此。
例如,由于如果多个终端上传相同的业务,且多个终端之间的距离越远,则业务下传效率越低,则n的取值还可根据多个终端的分布特征来进行调整,从而避免了到各个终端的多跳路径上的数据堆积。
这里需要说明的是,对于第一业务来说,在卫星通信系统包括M个终端的情况下,则可通过步骤S220,获取M个业务流行度值。
步骤S230,卫星根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端。其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。
应理解,卫星根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端的具体过程可根据实际需求来进行设置,本申请实施例并不局限于此。
可选地,卫星可根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,建立确定目标终端的问题模型,其中,问题模型用于最大化业务流行度加权下的卫星下行吞吐量(即保证选择的目标终端既是流行度比较高的终端,并且目标终端和卫星之间的信道状态也是比较好的),随后卫星可利用拉格朗日对偶算法获取问题模型的最优解,并将最优解对应的终端作为目标终端。
为了便于理解本申请实施例,下面通过具体地过程来进行描述。
具体地,由于地面网络侧倾向于将业务数据缓存在内容流行区域内的终端上,同时卫星侧倾向于选择星地链路信道状态更好的终端进行地面传输,本申请实施例可将地面网络和卫星在确定目标终端的决策上的交互问题表示成一个凸优化问题,并且可用xk,m表示缓存业务k的终端决策,如果xk,m=1,则表示终端m选择并缓存业务k的相关业务数据,即将终端m作为目标终端,否则xk,m=0。
以及,除了业务流行度之外,为了增大吞吐量本申请实施例还考虑了信道条件,本申请实施例的目标是最大化业务流行度加权下的卫星下行吞吐量。因此,本申请实施例建立了确定目标终端的问题模型,并且该问题模型如下:
Rk,m=Blog2(1+hmPk,m);
其中,Pk,m表示当终端m被选为目标终端时,卫星用于传输业务k相关的业务数据的功率,Rk,m表示卫星到终端m的下行吞吐量,B表示卫星用来传输单业务的统一信道带宽,hm表示卫星和终端m之间的信噪比。
这里需要说明的是,所有的下行链路传输的卫星功率之和不大于总可用卫星传输功率,具体可参见下式:
其中,PS表示总可用卫星传输功率。
另外,还可根据上述问题模型建立拉格朗日对偶问题:
给定α,最大化上述拉格朗日函数可以分解成K×M个子问题,以及给定业务缓存决策xk,m,并可通过独立优化这些子问题获得给定业务k的卫星发送功率,并可推到得到缓存决策。
以及,可将其中一个子问题L(k,m)记为wk,mRk,m-αPk,m,并且可令L(k,m)对于Pk,m的微分为零,并进行求解可获得最佳功率分配如下:
其中,(x)+表示max(0,x)。
应理解,这里的x仅是为了便于说明(x)+的公式的含义。
根据上述公式可以看出,即使不同的业务的需求终端数量相同,具有更集中的终端分布的业务也将获得更多的下行链路功率。这是因为较高的数据到达率很可能在较大范围的多跳节点上导致大量数据堆积,不利于网络稳定性。最优的业务缓存终端策略(k,m*)如下所示:
其中,m*表示最优解对应的终端m(或者说最优的业务缓存终端策略对应的终端m),wk,m表示终端m对应的业务流行度值,Rk,m表示卫星到终端m的下行传输功率,α为拉格朗日因子,hm表示卫星和终端m之间的信噪比。
以及,本申请实施例可以通过次梯度法求解对偶问题,并根据如下公式来更新拉格朗日因子α,具体地:
α(t+1)=[α(t)+η(t)Δ(t)]+;
其中,t表示迭代索引,η(t)表示预设的步长,并且η(t)大于0。
这里需要说明的是,拉格朗日对偶问题的最优解即为问题模型的最优解。
这里还需要说明的是,对于第一业务来说,在卫星通信系统包括M个终端的情况下,则可从M个终端中选取使得业务缓存终端策略的最优的终端。
此外,本申请实施例虽然步骤S210至步骤S240是以第一业务为例来进行描述的,但本领域的技术人员应当理解,对应其他的业务也可参照图2所示的流程进行处理。
因此,本申请实施例面向地域分布不均的业务需求,将用户间拓扑关系引入业务流行度定义,可根据网络拥塞状态及用户分布特征调整业务流行度大小,进而影响缓存终端决策,然后将卫星下行传输缓存决策表示成一个凸优化问题,旨在最大化业务流行度加权下的卫星下行吞吐量,在得到缓存决策的同时提出了相应的下行资源分配策略。
应理解,上述面向卫星的数据缓存终端选择方法仅是示例性的,本领域技术人员根据上述的方法可以进行各种变形,该变形之后的方案也属于本申请的保护范围。
请参见图3,图3示出了本申请实施例提供的一种面向卫星的数据缓存终端选择装置300的结构框图。应理解,该数据缓存终端选择装置300能够执行上述方法实施例中的各个步骤,该数据缓存终端选择装置300具体的功能可以参见上文中的描述,为避免重复,此处适当省略详细描述。该数据缓存终端选择装置300包括至少一个能以软件或固件(firmware)的形式存储于存储器中或固化在数据缓存终端选择装置300的操作系统(operating system,OS)中的软件功能模块。具体地,该数据缓存终端选择装置300应用于卫星通信系统中的卫星,卫星通信系统包括多个终端和卫星,多个终端处于卫星的覆盖范围内,该数据缓存终端选择装置300包括:
接收模块310,用于接收第一业务;其中,第一业务为接收的多种业务中的任意一种业务;
计算模块320,用于根据第一业务,计算多个终端中每个终端对应的业务流行度值;
选取模块330,用于根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,从多个终端中选取目标终端;其中,目标终端用于缓存卫星下发的与第一业务相关的业务数据。
在一个可能的实施例中,计算模块320,具体用于根据以下公式计算业务流行度值:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示终端m是否请求业务k,M(m,n)表示距终端m的跳数为预设跳数n的终端集合。
在一个可能的实施例中,预设跳数n是根据终端m和多个终端中除终端m之外的其他终端间的网络传输情况来确定的。
在一个可能的实施例中,选取模块330,具体用于:根据每个终端对应的业务流行度值以及卫星到每个终端的下行传输速率,建立确定目标终端的问题模型;其中,问题模型用于最大化业务流行度加权下的卫星下行吞吐量;利用拉格朗日对偶算法获取问题模型的最优解,并将最优解对应的终端作为目标终端。
在一个可能的实施例中,选取模块330,具体用于通过如下公式获取最优解:
其中,m*表示最优解对应的终端m,wk,m表示终端m对应的业务流行度值,Rk,m表示卫星到终端m的下行吞吐量,α为拉格朗日因子,hm表示卫星和终端m之间的信噪比。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置的具体工作过程,可以参考前述方法中的对应过程,在此不再过多赘述。
请参见图4,图4示出了本申请实施例提供的一种电子设备400的结构框图。如图4所示,电子设备400可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中,通信总线440用于实现这些组件直接的连接通信。其中,本申请实施例中设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片,具有信号的处理能力。上述的处理器410可以是通用处理器,包括中央处理器(CentralProcessing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(Digital Signal Processing,简称DSP)、专用集成电路(ApplicationSpecific Integrated Circuit,简称ASIC)、现场可编程逻辑门阵列(Field ProgrammableGate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。
存储器430可以是,但不限于,随机存取存储器(Random Access Memory,简称RAM),只读存储器(Read Only Memory,简称ROM),可编程只读存储器(Programmable Read-Only Memory,简称PROM),可擦除只读存储器(Erasable Programmable Read-OnlyMemory,简称EPROM),电可擦除只读存储器(Electric Erasable Programmable Read-OnlyMemory,简称EEPROM)等。存储器430中存储有计算机可读取指令,当计算机可读取指令由处理器410执行时,电子设备400可以执行上述方法实施例中的各个步骤。
电子设备400还可以包括存储控制器、输入输出单元、音频单元、显示单元。
存储器430、存储控制器、处理器410、外设接口、输入输出单元、音频单元、显示单元各元件相互之间直接或间接地电性连接,以实现数据的传输或交互。例如,这些元件相互之间可通过一条或多条通信总线440实现电性连接。处理器410用于执行存储器430中存储的可执行模块,例如电子设备400包括的软件功能模块或计算机程序。
输入输出单元用于提供给用户输入数据实现用户与服务器(或本地终端)的交互。输入输出单元可以是,但不限于,鼠标和键盘等。
音频单元向用户提供音频接口,其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。
显示单元在电子设备与用户之间提供一个交互界面(例如用户操作界面)或用于显示图像数据给用户参考。在本实施例中,显示单元可以是液晶显示器或触控显示器。若为触控显示器,其可为支持单点和多点触控操作的电容式触控屏或电阻式触控屏等。支持单点和多点触控操作是指触控显示器能感应到来自该触控显示器上一个或多个位置处同时产生的触控操作,并将该感应到的触控操作交由处理器进行计算和处理。
可以理解,图4所示的结构仅为示意,电子设备400还可包括比图4中所示更多或者更少的组件,或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。
本申请提供一种存储介质,该存储介质上存储有计算机程序,该计算机程序被处理器运行时执行实施例所述的方法。
本申请还提供一种计算机程序产品,所述计算机程序产品在计算机上运行时,使得计算机执行方法实施例所述的方法。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统的具体工作过程,可以参考前述方法中的对应过程,在此不再过多赘述。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。
Claims (6)
1.一种面向卫星的数据缓存终端选择方法,其特征在于,所述数据缓存终端选择方法应用于卫星通信系统中的卫星,所述卫星通信系统包括多个终端和所述卫星,所述多个终端处于所述卫星的覆盖范围内,所述数据缓存终端选择方法包括:
接收第一业务;其中,所述第一业务为接收的多种业务中的任意一种业务;
根据所述第一业务,计算所述多个终端中每个终端对应的业务流行度值,其中,所述业务流行度值为全局流行度或局部流行度,若预设跳数n的取值为最大跳数约束,则所述业务流行度值为所述全局流行度,若预设跳数n的取值小于最大跳数约束,则所述业务流行度值为所述局部流行度,所述预设跳数是根据第m终端和所述多个终端中除第m终端之外的终端之间的网络流量和预设流量的大小确定的;
其中,根据以下公式计算所述业务流行度值:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示所述终端m是否请求业务k,M(m,n)表示距所述终端m的跳数为预设跳数n的终端集合;
根据所述每个终端对应的业务流行度值以及所述卫星到所述每个终端的下行传输速率,从所述多个终端中选取目标终端;其中,所述目标终端用于缓存所述卫星下发的与所述第一业务相关的业务数据。
2.根据权利要求1所述的数据缓存终端选择方法,其特征在于,所述根据所述每个终端对应的业务流行度值以及所述卫星到所述每个终端的下行传输速率,从所述多个终端中选取目标终端,包括:
根据所述每个终端对应的业务流行度值以及所述卫星到所述每个终端的下行传输速率,建立确定所述目标终端的问题模型;其中,所述问题模型用于最大化业务流行度加权下的卫星下行吞吐量;
利用拉格朗日对偶算法获取所述问题模型的最优解,并将最优解对应的终端作为所述目标终端。
4.一种面向卫星的数据缓存终端选择装置,其特征在于,所述数据缓存终端选择装置应用于卫星通信系统中的卫星,所述卫星通信系统包括多个终端和所述卫星,所述多个终端处于所述卫星的覆盖范围内,所述数据缓存终端选择装置包括:
接收模块,用于接收第一业务;其中,所述第一业务为接收的多种业务中的任意一种业务;
计算模块,用于根据所述第一业务,计算所述多个终端中每个终端对应的业务流行度值,其中,所述业务流行度值为全局流行度或局部流行度,若预设跳数n的取值为最大跳数约束,则所述业务流行度值为所述全局流行度,若预设跳数n的取值小于最大跳数约束,则所述业务流行度值为所述局部流行度,所述预设跳数是根据第m终端和所述多个终端中除第m终端之外的终端之间的网络流量和预设流量的大小确定的;其中,根据以下公式计算所述业务流行度值:
其中,wk,m表示终端m对应的业务流行度值,ρk,m表示所述终端m是否请求业务k,M(m,n)表示距所述终端m的跳数为预设跳数n的终端集合;
选取模块,用于根据所述每个终端对应的业务流行度值以及所述卫星到所述每个终端的下行传输速率,从所述多个终端中选取目标终端;其中,所述目标终端用于缓存所述卫星下发的与所述第一业务相关的业务数据。
5.根据权利要求4所述的数据缓存终端选择装置,其特征在于,所述选取模块,具体用于:根据所述每个终端对应的业务流行度值以及所述卫星到所述每个终端的下行传输速率,建立确定所述目标终端的问题模型;其中,所述问题模型用于最大化业务流行度加权下的卫星下行吞吐量;利用拉格朗日对偶算法获取所述问题模型的最优解,并将最优解对应的终端作为所述目标终端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110525716.3A CN113271353B (zh) | 2021-05-13 | 2021-05-13 | 一种面向卫星的数据缓存终端选择方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110525716.3A CN113271353B (zh) | 2021-05-13 | 2021-05-13 | 一种面向卫星的数据缓存终端选择方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113271353A CN113271353A (zh) | 2021-08-17 |
CN113271353B true CN113271353B (zh) | 2022-09-06 |
Family
ID=77230796
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110525716.3A Active CN113271353B (zh) | 2021-05-13 | 2021-05-13 | 一种面向卫星的数据缓存终端选择方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113271353B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114337788A (zh) * | 2021-12-31 | 2022-04-12 | 浙江时空道宇科技有限公司 | 铱星设备控制方法、设备及系统 |
CN114827179A (zh) * | 2022-05-05 | 2022-07-29 | 鹏城实验室 | 一种面向卫星网格的缓存方法及相关装置 |
CN115665804B (zh) * | 2022-11-21 | 2023-03-14 | 昆明理工大学 | 一种协同无人机-智能车群的缓存优化方法 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112332898A (zh) * | 2020-08-31 | 2021-02-05 | 航天科工空间工程发展有限公司 | 一种基于宽带存储转发模式的卫星通信方法和系统 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110535897B (zh) * | 2018-05-25 | 2020-10-20 | 北京邮电大学 | 天地一体化网络的数据缓存方法和装置 |
-
2021
- 2021-05-13 CN CN202110525716.3A patent/CN113271353B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112332898A (zh) * | 2020-08-31 | 2021-02-05 | 航天科工空间工程发展有限公司 | 一种基于宽带存储转发模式的卫星通信方法和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN113271353A (zh) | 2021-08-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113271353B (zh) | 一种面向卫星的数据缓存终端选择方法和装置 | |
CN111132077B (zh) | 车联网环境下基于d2d的多接入边缘计算任务卸载方法 | |
US9860758B2 (en) | Systems and methods for placing virtual serving gateways for mobility management | |
Wang et al. | Adaptive wireless video streaming based on edge computing: Opportunities and approaches | |
Tran et al. | Cooperative hierarchical caching and request scheduling in a cloud radio access network | |
US10129356B2 (en) | Physical layer caching for flexible MIMO cooperation in wireless networks | |
US20130034016A1 (en) | Method and system for transferring information in vehicular wireless networks | |
US10791495B2 (en) | Device, method and user equipment in a wireless communication system | |
US10447616B2 (en) | Broadcast services platform and methods for use therewith | |
Huang et al. | Towards 5G: Joint optimization of video segment caching, transcoding and resource allocation for adaptive video streaming in a multi-access edge computing network | |
Liu et al. | MEC-assisted flexible transcoding strategy for adaptive bitrate video streaming in small cell networks | |
Huang et al. | Reliable realtime streaming in vehicular cloud-fog computing networks | |
CN110248206A (zh) | 一种用于边缘网络系统的资源分配方法、装置及电子设备 | |
Mekala et al. | Deep learning‐influenced joint vehicle‐to‐infrastructure and vehicle‐to‐vehicle communication approach for internet of vehicles | |
Al-Hilo et al. | Vehicle-assisted RSU caching using deep reinforcement learning | |
AU2015230738A1 (en) | Utility-based cross layering | |
KR101645409B1 (ko) | 네트워크 트래픽 감소를 위한 캐싱 방법 | |
WO2017113373A1 (zh) | 一种缓存的方法及分组数据网关 | |
Siris et al. | Exploiting mobility prediction for mobility & popularity caching and DASH adaptation | |
Chowdhury et al. | An optimal strategy for UAV-assisted video caching and transcoding | |
Al-Habashna et al. | QoE awareness in progressive caching and DASH-based D2D video streaming in cellular networks | |
CN116887356A (zh) | 一种基于sfn分区的星地一体计算卸载和资源分配方法 | |
Delgado et al. | Video-streaming transmission with qos over cross-layered ad hoc networks | |
WO2023009382A1 (en) | Method and system for distributing content by pre-positioning and redistributing the content to other devices | |
Tran et al. | Downlink resource allocation maximized video delivery capacity over multi-hop multi-path in dense D2D 5G networks |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |