WO2014032489A1 - 一种推送业务的实现方法和设备 - Google Patents

一种推送业务的实现方法和设备 Download PDF

Info

Publication number
WO2014032489A1
WO2014032489A1 PCT/CN2013/080106 CN2013080106W WO2014032489A1 WO 2014032489 A1 WO2014032489 A1 WO 2014032489A1 CN 2013080106 W CN2013080106 W CN 2013080106W WO 2014032489 A1 WO2014032489 A1 WO 2014032489A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal device
service
network side
side device
information
Prior art date
Application number
PCT/CN2013/080106
Other languages
English (en)
French (fr)
Inventor
董靖宇
Original Assignee
中国移动通信集团公司
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 中国移动通信集团公司 filed Critical 中国移动通信集团公司
Publication of WO2014032489A1 publication Critical patent/WO2014032489A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method and an apparatus for implementing a push service. Background technique
  • the broadcast mobile TV service is a service that delivers mobile TV media content through broadcast, which is characterized by one-way downlink and one-to-one transmission of TV program content.
  • the user interacts with the server in the business order, that is, the right to use the broadcast mobile TV service (ie, the service key), and in the process of watching the television program, the terminal is in a passive receiving state, and There is no interaction on the network side. That is to say, the network side only broadcasts the TV program by broadcasting, and does not know which users are watching which programs.
  • Free-time push refers to the use of the idle time (different from busy time) network resources of the broadcast network or the mobile communication network to actively push the multimedia content to the terminal without the user's perception.
  • the terminal no longer obtains the content in real time from the network, but directly presents the content stored in the terminal to the user, and separates the transmission process from the use process, and transmits the content to the terminal locally without user operation.
  • the design of the prior art solution is: CMMB is caused every time the client exits. When the chip is powered off, the corresponding service key will be deleted. The next time the user uses the service, he needs to request the service key again.
  • This scheme is applicable to the live broadcast service because the behavior of the user using the live broadcast service is very discrete, so the service key request does not impose high requirements on the load capacity of the server.
  • the terminal is controlled by the scheduling information, and the startup time is the time when the service push starts, that is, the startup time is the same for all the terminals, if the service key request is initiated in a time period concentrated near the time point. This may result in a large-scale expansion of the server, an increase in equipment investment, and may cause the terminal to request a key failure, which may affect the execution of subsequent business logic.
  • the present invention provides a method and a device for implementing a push service, which are used to discretely push a large number of concurrent requests of a service terminal device to impact on a server, thereby improving system stability.
  • the embodiment of the present invention adopts the following technical solutions:
  • a method for implementing a push service comprising: sending, by a network side device, scheduling information of a push service to a terminal device, so that the terminal device determines, according to the received scheduling information, a time for sending a service key acquisition request; wherein the scheduling The information includes a time point of each service push of the network side device, and information for scheduling and controlling the service key of the terminal device;
  • the network side device receives the service key acquisition request sent by the terminal device, sending a service key to the terminal device, so that the terminal device decrypts the received service according to the service key.
  • a method for implementing a push service comprising: receiving, by a terminal device, scheduling information of a push service delivered by a network side device; wherein, the scheduling information The information includes a time point of each service push of the network side device, and information for scheduling and controlling the service key of the terminal device;
  • the terminal device decrypts the received service pushed by the network side device according to the obtained service key.
  • a network side device including:
  • a first sending module configured to send, to the terminal device, scheduling information of the push service, so that the terminal device determines, according to the received scheduling information, a time for sending a service key acquisition request, where the scheduling information includes a network side device a point in time at which each service is pushed, and information for scheduling and controlling a service key for the terminal device;
  • a receiving module configured to receive a service key acquisition request sent by the terminal device
  • a terminal device comprising:
  • a receiving module configured to receive scheduling information of a push service delivered by the network side device, where the scheduling information includes a time point for each service of the network side device, and a request for scheduling the service key for the terminal device Controlled information;
  • a sending module configured to determine, according to the scheduling information received by the first receiving module, the acquiring service confidentiality The time of the key, and the key acquisition request is sent to the network side device according to the time; the decryption module is configured to decrypt the received service pushed by the network side device according to the obtained key.
  • the network side device sends the scheduling information of the push service to the terminal device, where the scheduling information carries the time point of each service push of the network side device, and is used for scheduling the service key of the terminal device.
  • Controlling information after receiving the scheduling information of the push service delivered by the network side device, the terminal device determines a time point for requesting the service key from the network side device according to the scheduling information, and sends the service confidentiality to the network side device at the time point.
  • the network side device After receiving the service key acquisition request sent by the terminal device, the network side device sends a service key to the terminal device, and the terminal device pairs the encrypted file included in the received service according to the received service key. Decrypting, discarding the impact of concurrent requests from a large number of push service terminal devices on the server, improves system stability.
  • FIG. 1 is a schematic flowchart of a method for implementing a push service according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a method for implementing a push service according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a terminal device according to an embodiment of the present invention. detailed description
  • the embodiments of the present invention provide a technical solution for implementing a push service.
  • the network side device sends the scheduling information of the push service to the terminal device, where the scheduling information carries the time point of each service push of the network side device, and is used for scheduling and controlling the service key of the terminal device.
  • the terminal device receives the network side device delivery After the scheduling information of the service is pushed, the time point for requesting the service key from the network side device is determined according to the scheduling information, and the service key acquisition request is sent to the network side device at the time point; the network side device receives the sending by the terminal device After the service key acquisition request, the service key is sent to the terminal device, and the terminal device decrypts the encrypted file included in the received service according to the received service key.
  • a schematic flowchart of a method for implementing a push service may include the following steps:
  • Step 101 The network side device sends the scheduling information of the push service to the terminal device, where the time point of each service push of the network side device and the information for scheduling and controlling the service key of the terminal device are carried.
  • the network side device may send, to the terminal device, a push time point including each service, and scheduling information used for scheduling and controlling the service key of the terminal device, so that the terminal device according to the scheduling The information sends a key acquisition request to the network side.
  • the network side device may send the scheduling information of the push service to the terminal device, or may periodically or periodically send the terminal device to the terminal device.
  • the scheduling information of the push service is delivered.
  • the terminal device can be opened
  • the scheduling information acquisition request is sent to the network side device when the client is running, or the terminal device may send the scheduling information acquisition request to the network side device according to the user's instruction.
  • Step 102 The terminal device receives the scheduling information of the push service delivered by the network side device, and sends a service key acquisition request to the network side device according to the received scheduling information.
  • the terminal device may use the time point of pushing each service of the network side device carried in the scheduling information of the push service, and request the service confidentiality for the terminal device.
  • the information for scheduling and controlling the key determines the time at which the service key acquisition request is sent, and sends a service key acquisition request to the network side device according to the determined time.
  • Step 103 When the network side device receives the service key acquisition request sent by the terminal device, the device sends a service key to the terminal device.
  • Step 104 The terminal device decrypts the encrypted file included in the service pushed by the network side device according to the received service key.
  • the information for scheduling and controlling the request for the service key of the terminal device carried in the scheduling information of the push service delivered by the network device to the terminal device may be specifically used for controlling the terminal.
  • the time when the device sends the request service key such as sending the service key acquisition request before the service push starts, sending the service key acquisition request in the process of the service push, or sending the service key acquisition request after the service push ends.
  • the specific time for the terminal device to send the service key acquisition request may be determined by the terminal device according to the time interval of the request for generating the key carried in the scheduling information sent by the network device, and the random number generated by the terminal device.
  • the network side device pushes the service to the terminal device by means of the broadcast
  • the large number of terminal devices receive the data sent by the network side device
  • the terminal device may receive the file error due to factors such as the network environment in which the terminal device is located.
  • the network side device usually File repair is done through the mechanism of file retransmission.
  • the network side device cannot resend all the pushed services to ensure that each device can receive the corresponding service normally.
  • the scheduling information of the push service sent by the network side device to the terminal device may further include: the service that the network side device pushes to the terminal device.
  • the terminal device determines whether all the files included in the service pushed by the network side device are normally received according to the scheduling information, and determines whether it sends a file repair request to the network side device when the received file is in error.
  • a method for implementing a push service may further include the following steps:
  • Step 105 The terminal device determines, according to the received scheduling information, whether file repair is required. If the determination is yes, go to step 106; otherwise, the process ends.
  • the terminal device may determine, according to the time point of each service pushed by the network side device included in the scheduling information, the identifier and file size of the file included in each service, and the file included in the service pushed by the network side device received by the terminal device. Whether the files included in the service pushed by the network-side device are all received normally. If the result of the determination is that all the normal reception is performed, it is determined that the file repair is not required; if the result of the determination is that all the normal reception is not performed, the information for scheduling and controlling the behavior of initiating the file repair request for the terminal device included in the scheduling information is further determined. Determine if file repair is required.
  • the terminal device If the signal noise ratio is low (the network condition of the terminal device is poor), if the terminal device initiates file repair, the file retransmitted by the network device may still be unable to be positive by the terminal device. Often received, therefore, the terminal device that can set the average SNR in the process of receiving the service pushed by the network side device below a certain threshold does not need to initiate file repair.
  • the information for scheduling and controlling the behavior of the terminal device to initiate the file repair request included in the scheduling information of the push service delivered by the network side device may be information for indicating the receiving push industry, and a specific threshold. value.
  • the terminal device After determining that the terminal device does not normally receive the service pushed by the network side device, the terminal device determines an average SNR in the process of receiving the service pushed by the network side device, and determines whether it exceeds the set SNR threshold, and determines whether When the result is YES, it is determined that file repair is required; when it is judged as No, it is determined that file repair is not required.
  • the terminal device that can set the amount of lost data exceeding the preset threshold does not need to initiate file repair.
  • the information for scheduling and controlling the behavior of the terminal device to initiate the file repair request included in the scheduling information of the push service delivered by the network device may be the terminal device for indicating that the data loss does not exceed the threshold to the network.
  • the side device sends the information of the file repair request, as well as the specific threshold.
  • the terminal device After determining that the terminal device does not normally receive the service pushed by the network side device, the terminal device collects the amount of data lost by itself, and determines whether it exceeds the set threshold, and when the determination result is yes, determines that the file is not required. Fix; When the judgment is no, it is determined that file repair is required.
  • the implementation of the behavior scheduling and control is only two specific implementations of the technical solutions provided by the embodiments of the present invention, and is not limited to the scope of the present invention. On the basis of the embodiments of the present invention, those skilled in the art do not go through Modifications made to them under the premise of creative labor are within the scope of protection of the present invention.
  • Step 106 The terminal device sends a file repair request to the network side device.
  • the file repair request includes at least the identifier of the terminal device and the identifier of the file lost by the terminal device.
  • Step 107 The network side device receives the file repair request sent by the terminal device, determines a file that needs to be retransmitted according to the received file repair request, and performs file retransmission.
  • the network side device After receiving the file repair request sent by each terminal device, the network side device acquires the identifier of each terminal device, and the identifier of the file requested by each terminal device in the file repair request, and retransmits according to the obtained request.
  • the identifier of the file and the network side device can determine the file retransmitted to each terminal device by the amount of data sent by the retransmission, and send an indication message to the corresponding terminal device, indicating that the corresponding terminal device accepts the network side device at a specific time. Transmitted documents.
  • the network side device can preferentially send files with a large number of terminal devices requesting retransmission.
  • Step 108 The terminal device receives the file retransmitted by the network side device.
  • the terminal device can receive the retransmitted file on the network side through the broadcast network or the mobile communication network at a specific time according to the indication message sent by the network side device.
  • information for scheduling and controlling key acquisition and file repair is added to the scheduling information of the push service delivered by the network device to the terminal device.
  • the behavior of the terminal device in the push service is controlled more precisely, and the load on the network side device caused by the large number of terminal devices transmitting the key acquisition request at the same time is avoided. It also improves the accuracy and efficiency of file retransmission by network side devices.
  • the embodiment of the present invention further provides a network side device, which can be applied to the above process.
  • a schematic structural diagram of a network side device may include:
  • the first sending module 31 is configured to send, to the terminal device, scheduling information of the push service, so that the terminal device determines, according to the received scheduling information, a time for sending a service key acquisition request, where the scheduling information includes a network side. A point in time at which each service of the device is pushed, and information for scheduling and controlling a service key for the terminal device;
  • the receiving module 32 is configured to receive a service key acquisition request sent by the terminal device
  • a second sending module 33 configured to: when the receiving module 32 receives the service key acquisition request sent by the terminal device, send a service key to the terminal device, so that the terminal device receives the service key pair according to the service key pair The business to be decrypted.
  • the first sending module 31 is specifically configured to: when the receiving module receives the scheduling information acquisition request sent by the terminal device, send the scheduling information of the pushing service to the terminal device; or, according to a preset period The scheduling information of the push service is delivered to the terminal device.
  • the scheduling information further includes: an identifier and a file size of the file included in each service pushed by the network side device, and information for scheduling and controlling the behavior of the terminal device initiating the file repair request;
  • the receiving module 32 is further configured to: receive a file repair request sent by the terminal device, where the identifier of the terminal device is included, and an identifier of the file that the terminal device requests to retransmit;
  • the network side device further includes:
  • the third sending module 34 is configured to determine, according to the file repair request received by the receiving module 32, the file that needs to be retransmitted, and send an indication message to the terminal device, to instruct the corresponding terminal device to receive the requested retransmitted file at a specific time; The identified files that need to be retransmitted.
  • the information that the terminal device requests the service key for scheduling and control is specifically: the information indicating that the terminal device sends the service key acquisition request before the service push starts, during the service push process, or after the service push ends.
  • the information for scheduling and controlling the behavior of the terminal device initiating the file repair request is:
  • FIG. 4 is a schematic structural diagram of a terminal device according to an embodiment of the present invention, which may include
  • the receiving module 41 is configured to receive scheduling information of a push service delivered by the network side device, where the scheduling information includes a time point of each service push of the network side device, and is used to request a service key for the terminal device to be scheduled. And control information;
  • the sending module 42 is configured to determine, according to the scheduling information received by the receiving module 41, a time for acquiring a service key, and send a key acquisition request to the network side device according to the time;
  • the decryption module 43 is configured to decrypt the received service pushed by the network side device according to the obtained key.
  • the receiving module 41 is specifically configured to: send, by the sending module 42, a scheduling information acquisition request to the network side device, and receive scheduling information of a push service delivered by the network side device; or, receive the The scheduling information of the push service delivered by the network side device periodically. And file size, and information for scheduling and controlling the behavior of the terminal device initiating a file repair request;
  • the terminal device further includes:
  • the determining module 44 is configured to determine, according to the scheduling information and the service pushed by the network side device received by the receiving module, whether a file repair request needs to be sent to the network side device;
  • the sending module 42 is further configured to: when the determining module 44 determines YES, send a file repair request to the network side device;
  • the receiving module 41 is further configured to: receive an indication message sent by the network side device, and receive a file that is retransmitted by the network side device according to the indication message; where the indication message is used to indicate the terminal The device receives the requested retransmitted file at a specific time.
  • the information for requesting the terminal device to request the service key for scheduling and control is specifically:
  • the information for scheduling and controlling the behavior of the terminal device to initiate the file repair request is specifically: indicating that the terminal device whose average signal to noise ratio exceeds the threshold during the process of receiving the service pushed by the network device sends a file repair to the network side device Requested information and threshold values; or,
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for causing a A computer device (which may be a personal computer, server, or network device, etc.) performs the methods described in various embodiments of the present invention.
  • modules in the apparatus in the embodiment may be described in the apparatus distributed in the embodiment according to the embodiment, or may be correspondingly changed in one or more apparatuses different from the embodiment.
  • the modules of the above embodiments may be combined into one module, or may be further split into a plurality of sub-modules.

Abstract

一种推送业务的实现方法和设备,该方法包括网络侧设备向终端设备下发推送业务的调度信息,;当网络侧设备接收到终端设备发送的业务密钥获取请求时,向终端设备发送业务密钥,终端设备根据业务密钥对业务进行解密。

Description

一种推送业务的实现方法和设备
本申请要求于 2012 年 8 月 31 号提交中国专利局、 申请号为 201210317525.9、 发明名称为 "一种推送业务的实现方法和设备" 的中国 专利申请的优先权, 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信技术领域, 尤其涉及一种推送业务的实现方法和设备。 背景技术
广播式手机电视业务是一种通过广播方式下发手机电视媒体内容的业务, 其特点是电视节目内容的单向下行、 一点到面的传输。 在业务使用过程中, 用 户与服务器进行交互的环节是业务订购,即获得广播式手机电视业务的使用权 限(即业务密钥), 在收看电视节目的过程中, 终端处于被动接收的状态, 与 网络侧没有交互, 也就是说, 网络侧只是通过广播方式把电视节目播放出去, 并不知道哪些用户在收看哪些节目。 闲时推送是指利用广播网络或者移动通信网络的闲时(区别于忙时)网络 资源,将多媒体内容在用户不感知的情况下主动推送到终端。 当用户使用业务 时, 终端不再从网络实时获取内容, 而是直接把存储在终端本地的内容呈现给 用户,通过把传输过程和使用过程相分离, 并无需用户操作将内容传输到终端 本地, 给用户提供一种使用本地业务的体验。 考虑到若业务密钥在 CMMB芯片下电后仍然长期有效,可能导致业务密钥 被盗取和传播, 危害业务发展, 因此现有技术中的方案的设计是: 每次客户端 退出都会导致 CMMB芯片下电, 相应的, 业务密钥将被删除。 用户下次使用业 务时需要再次请求业务密钥。 这种方案对直播业务是适用的,因为用户使用直播业务的行为是非常离散 的, 所以业务密钥请求并不会对服务器的负荷能力提出高要求。但是对于推送 业务, 终端受控于调度信息, 启动的时间就是业务推送开始的时间, 即, 启动 时间对所有终端都是相同的,如果集中在这个时间点附近的一个时间段发起业 务密钥请求, 可能导致服务器需要大规模扩容, 增加设备投资, 而且可能导致 终端请求密钥失败, 影响后续业务逻辑的执行。 发明内容
本发明提供了一种推送业务的实现方法和设备,以离散大量推送业务终端 设备的并发请求对服务器的冲击, 提高系统稳定性。 为了达到以上目的, 本发 明实施例采用如下技术方案:
一种推送业务的实现方法, 包括: 网络侧设备向终端设备下发推送业务的调度信息,以使所述终端设备根据 接收到的调度信息确定发送业务密钥获取请求的时间;其中所述调度信息包含 有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务密钥进行 调度和控制的信息;
当所述网络侧设备接收到终端设备发送的业务密钥获取请求时,向所述终 端设备发送业务密钥,以使所述终端设备根据所述业务密钥对接收到的业务进 行解密。
一种推送业务的实现方法, 包括: 终端设备接收网络侧设备下发的推送业务的调度信息; 其中, 所述调度信 息中包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务 密钥进行调度和控制的信息;
所述终端设备根据接收到的调度信息确定获取业务密钥的时间,并根据该 时间向所述网络侧设备发送密钥获取请求;
所述终端设备根据获取到的业务密钥对接收到的所述网络侧设备推送的 业务进行解密。 一种网络侧设备, 包括:
第一发送模块, 用于向终端设备下发推送业务的调度信息, 以使所述终端 设备根据接收到的调度信息确定发送业务密钥获取请求的时间;其中所述调度 信息包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务 密钥进行调度和控制的信息;
接收模块, 用于接收终端设备发送的业务密钥获取请求;
第二发送模块,用于当所述接收模块接收到终端设备发送的业务密钥获取 请求, 向所述终端设备发送业务密钥, 以使所述终端设备根据所述业务密钥对 接收到的业务进行解密。 一种终端设备, 包括:
接收模块, 用于接收网络侧设备下发的推送业务的调度信息; 其中, 所述 调度信息中包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请 求业务密钥进行调度和控制的信息;
发送模块,用于根据所述第一接收模块接收到的调度信息确定获取业务密 钥的时间, 并根据该时间向所述网络侧设备发送密钥获取请求; 解密模块,用于根据获取到的密钥对接收到的所述网络侧设备推送的业务 进行解密。
本发明上述实施例中, 网络侧设备向终端设备下发推送业务的调度信息, 该调度信息中携带有网络侧设备各个业务推送的时间点,以及用于对终端设备 请求业务密钥进行调度和控制的信息;终端设备接收到网络侧设备下发的推送 业务的调度信息后, 根据该调度信息确定向网络侧设备请求业务密钥的时间 点, 并在该时间点向网络侧设备发送业务密钥获取请求; 网络侧设备接收到终 端设备发送的业务密钥获取请求后, 向终端设备发送业务密钥, 由该终端设备 根据接收到的业务密钥对接收到的业务中所含的加密文件进行解密,离散了大 量推送业务终端设备的并发请求对服务器的冲击, 提高了系统稳定性。
附图说明
图 1为本发明实施例提供的一种推送业务的实现方法的流程示意图; 图 2为本发明实施例提供的一种推送业务的实现方法的流程示意图; 图 3为本发明实施例提供的一种网络侧设备的结构示意图;
图 4为本发明实施例提供的一种终端设备的结构示意图。 具体实施方式
针对上述现有技术中存在的问题,本发明实施例提供了一种推送业务的实 现的技术方案。在该技术方案中, 网络侧设备向终端设备下发推送业务的调度 信息, 该调度信息中携带有网络侧设备各个业务推送的时间点, 以及用于对终 端设备请求业务密钥进行调度和控制的信息;终端设备接收到网络侧设备下发 的推送业务的调度信息后,根据该调度信息确定向网络侧设备请求业务密钥的 时间点, 并在该时间点向网络侧设备发送业务密钥获取请求; 网络侧设备接收 到终端设备发送的业务密钥获取请求后, 向终端设备发送业务密钥, 由该终端 设备根据接收到的业务密钥对接收到的业务中所含的加密文件进行解密。
下面将结合本申请中的附图,对本申请中的技术方案进行清楚、 完整的描 述, 显然, 所描述的实施例是本申请的一部分实施例, 而不是全部的实施例。 基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下 所获得的所有其他实施例, 都属于本申请保护的范围。
如图 1所示,为本发明实施例提供的一种推送业务的实现方法的流程示意 图, 可以包括以下步骤:
步骤 101、 网络侧设备向终端设备下发推送业务的调度信息, 其中携带有 网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务密钥进行调 度和控制的信息。
具体的, 为了对终端设备获取业务密钥的时间进行控制,避免出现因各终 端设备在某个时间点集中发起业务密钥获取请求而导致网络侧设备负荷过大 的问题,在本发明实施例提供的技术方案中, 网络侧设备可以向终端设备下发 包含有各个业务的推送时间点,以及用于对终端设备请求业务密钥进行调度和 控制的信息的调度信息,以使终端设备根据该调度信息向网络侧发送密钥获取 请求。
在本发明实施例提供的技术方案中,网络侧设备可以在接收到终端设备发 送的调度信息获取请求后, 向该终端设备下发推送业务的调度信息,也可以定 时或周期性地向终端设备下发推送业务的调度信息。其中, 终端设备可以在开 始运行客户端时向网络侧设备发送调度信息获取请求,或终端设备可以根据用 户的指令向网络侧设备发送调度信息获取请求。
步骤 102、 终端设备接收网络侧设备下发的推送业务的调度信息, 并根据 接收到的调度信息向网络侧设备发送业务密钥获取请求。
具体的, 终端设备接收到网络侧设备下发的推动业务的调度信息后, 可以 根据该推动业务的调度信息中携带的网络侧设备各业务推送的时间点,以及用 于对终端设备请求业务密钥进行调度和控制的信息确定发送业务密钥获取请 求的时间, 并根据所确定的时间向网络侧设备发送业务密钥获取请求。
步骤 103、 当网络侧设备接收到终端设备发送的业务密钥获取请求时, 向 所述终端设备发送业务密钥。
步骤 104、 终端设备根据接收到的业务密钥对网络侧设备所推送的业务中 所包含的加密文件进行解密。
在本发明实施例提供的技术方案中,网络侧设备向终端设备下发的推送业 务的调度信息中携带的用于对终端设备请求业务密钥进行调度和控制的信息, 可以具体用于控制终端设备发送请求业务密钥的时间 ,如在业务推送开始前发 送业务密钥获取请求、在业务推送的过程中发送业务密钥获取请求、或在业务 推送结束之后发送业务密钥获取请求。其中, 终端设备发送业务密钥获取请求 的具体时间,可以由终端设备根据网络侧设备下发的调度信息中携带的发起密 钥请求的时间间隔、 以及终端设备生成的随机数确定。
进一步地, 当网络侧设备通过广播的方式向终端设备推送业务时, 大量终 端设备接收网络侧设备发送的数据,很可能出现由于终端设备所处的网络环境 等因素而导致终端设备接收文件出错的问题。在这种情况下, 网络侧设备通常 通过文件重传的机制来进行文件修复。但由于网络侧设备进行文件重传的时间 有限,网络侧设备通常无法将所有推送的业务都重新发送以保证各设备均能正 常接收相应的业务。
针对以上现有技术中可能出现的问题, 在本发明实施例提供的技术方案 中, 网络侧设备向终端设备发送的推送业务的调度信息中还可以包括: 网络侧 设备向终端设备推送的业务中所包含文件的标识和文件大小,以及用于对终端 设备发起文件修复请求的行为进行调度和控制的信息。终端设备可以根据该调 度信息确定网络侧设备推送的业务中包含的文件是否全部正常接收,并当接收 文件出错时, 确定自身是否向网络侧设备发送文件修复请求。
在该情况下,如图 2所示, 本发明实施例提供的一种推送业务的实现方法 流程中还可以包括以下步骤:
步骤 105、 终端设备根据接收到的调度信息判断是否需要进行文件修复。 若判断为是, 则转至步骤 106; 否则, 结束流程。
具体的,终端设备可以根据调度信息中包含的网络侧设备各个业务推送的 时间点、各个业务所包含的文件的标识和文件大小, 以及自身接收到的网络侧 设备推送的业务中包含的文件判断网络侧设备推送的业务中包含的文件是否 全部正常接收。 若判断结果为全部正常接收, 则确定不需要进行文件修复; 若 判断结果为未全部正常接收,则进一步根据调度信息中包含的用于对终端设备 发起文件修复请求的行为进行调度和控制的信息确定是否需要进行文件修复。
其中, 当终端设备在接收网络侧设备推送的业务的过程中的平均 SNR
( Signal Noise Ratio, 信噪比 )较低时 (该终端设备所处网络状况较差), 则若 终端设备发起文件修复,网络侧设备重传的文件仍有可能不能被该终端设备正 常接收, 因此, 可以设定在接收网络侧设备推送的业务的过程中的平均 SNR 低于一定门限值的终端设备不需要发起文件修复。
相应地,网络侧设备下发的推送业务的调度信息中包含的用于对终端设备 发起文件修复请求的行为进行调度和控制的信息可以为用于指示接收推送业 的信息, 以及具体的门限值。
终端设备在确定自身未全部正常接收网络侧设备推送的业务后,终端设备 确定在接收网络侧设备推送的业务的过程中的平均 SNR, 并判断其是否超过 所设定的 SNR门限, 并当判断结果为是时, 确定需要进行文件修复; 当判断 为否时, 确定不需要进行文件修复。
此外, 由于网络侧设备通过重传的方式发送的数据量有限, 当终端设备丟 失的数据量 (即未能正常接收的文件的大小 )超过网络侧设备能重传的数据量 时,终端设备无法通过请求网络侧设备进行文件重传的方式来使自身全部正常 接收网络侧设备推送的业务中包含的文件。 因此,在本发明实施例提供的技术 方案中, 可以设定丟失数据量超过预设门限的终端设备不需要发起文件修复。
相应地,网络侧设备下发的推送业务的调度信息中包含的用于对终端设备 发起文件修复请求的行为进行调度和控制的信息可以为用于指示数据丟失量 不超过门限的终端设备向网络侧设备发送文件修复请求的信息,以及具体的门 限值。
终端设备在确定自身未全部正常接收网络侧设备推送的业务后,终端设备 统计自己丟失的数据量, 并判断其是否超过所设定的门限, 并当判断结果为是 时, 确定不需要进行文件修复; 当判断为否时, 确定需要进行文件修复。 行为进行调度和控制的实现方式仅仅是本发明实施例提供的技术方案的两种 具体实现, 而不是对本发明保护范围的限定, 在本发明实施例的基石出上, 本领 域技术人员在不经过创造性劳动前提下对其进行的变型均属于本发明的保护 范围。
步骤 106、 终端设备向网络侧设备发送文件修复请求。 其中, 该文件修复 请求中至少包含有终端设备的标识, 终端设备丟失的文件的标识。
步骤 107、 网络侧设备接收终端设备发送的文件修复请求, 根据接收到的 文件修复请求确定需要重传的文件, 并进行文件重传。
具体的, 网络侧设备接收到各终端设备发送的文件修复请求后, 获取各终 端设备的标识, 以及文件修复请求中各终端设备请求重传的文件的标识, 并根 据获取到的请求重传的文件的标识以及网络侧设备能过通过重传的方式发送 的数据量确定向各终端设备重传的文件, 并向相应的终端设备发送指示消息, 指示相应终端设备在特定时间接受网络侧设备重传的文件。其中, 网络侧设备 可以优先发送请求重传的终端设备数量较多的文件。
步骤 108、 终端设备接收网络侧设备重传的文件。
具体的, 终端设备可以根据网络侧设备下发的指示消息,在特定时间点通 过广播网络或移动通信网络接收网络侧重传的文件。
通过以上描述可以看出,在本发明实施例提供的技术方案中,通过在网络 侧设备向终端设备下发的推送业务的调度信息中增加对密钥获取和文件修复 进行调度和控制的信息, 更加精确地控制终端设备在推送业务中的行为,避免 了网络侧设备因大量终端设备在同一时刻发送密钥获取请求导致的负荷过大, 并提高了网络侧设备进行文件重传的准确率和效率。
基于与上述方法流程相同的技术构思,本发明实施例中还提供了一种网络 侧设备, 可以运用于上述流程。
如图 3所示, 为本发明实施例提供的一种网络侧设备的结构示意图, 可以 包括:
第一发送模块 31 , 用于向终端设备下发推送业务的调度信息, 以使所述 终端设备根据接收到的调度信息确定发送业务密钥获取请求的时间;其中所述 调度信息包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请求 业务密钥进行调度和控制的信息;
接收模块 32, 用于接收终端设备发送的业务密钥获取请求;
第二发送模块 33 , 用于当所述接收模块 32接收到终端设备发送的业务密 钥获取请求, 向所述终端设备发送业务密钥, 以使所述终端设备根据所述业务 密钥对接收到的业务进行解密。
其中, 所述第一发送模块 31具体用于, 当所述接收模块接收到终端设备 发送的调度信息获取请求时, 向所述终端设备下发推送业务的调度信息; 或, 根据预设的周期向终端设备下发推送业务的调度信息。
其中,所述调度信息中还包含有网络侧设备推送的各个业务所包含的文件 的标识和文件大小 ,以及用于对终端设备发起文件修复请求的行为进行调度和 控制的信息;
所述接收模块 32还用于, 接收终端设备发送的文件修复请求, 其中包含 有终端设备的标识, 以及该终端设备请求重传的文件的标识;
该网络侧设备还包括: 第三发送模块 34 , 用于根据接收模块 32接收到的文件修复请求确定需要 重传的文件, 并向终端设备发送指示消息,指示相应终端设备在特定时间接收 所请求重传的文件; 重传所确定的需要重传的文件。
其中, 所述对终端设备请求业务密钥进行调度和控制的信息具体为: 指示终端设备在业务推送开始之前、业务推送过程中、或业务推送结束之 后发送业务密钥获取请求的信息。
其中,所述对终端设备发起文件修复请求的行为进行调度和控制的信息具 体为:
指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端 设备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丟失的数据量不超过门限的 终端设备向所述网络侧设备发送文件修复请求的信息以及门限值。 如图 4所示, 为本发明实施例提供的一种终端设备的结构示意图, 可以包 括
接收模块 41 , 用于接收网络侧设备下发的推送业务的调度信息; 其中, 所述调度信息中包含有网络侧设备各个业务推送的时间点,以及用于对终端设 备请求业务密钥进行调度和控制的信息;
发送模块 42, 用于根据所述接收模块 41接收到的调度信息确定获取业务 密钥的时间, 并根据该时间向所述网络侧设备发送密钥获取请求;
解密模块 43 , 用于根据获取到的密钥对接收到的所述网络侧设备推送的 业务进行解密。 其中 , 所述接收模块 41具体用于, 通过所述发送模块 42向所述网络侧设 备发送调度信息获取请求, 并接收所述网络侧设备下发的推送业务的调度信 息; 或, 接收所述网络侧设备周期性下发的推送业务的调度信息。 和文件大小,以及用于对终端设备发起文件修复请求的行为进行调度和控制的信 息;
所述终端设备还包括:
判断模块 44 , 用于根据所述调度信息以及所述接收模块接收到的网络侧设 备推送的业务确定是否需要向所述网络侧设备发送文件修复请求;
所述发送模块 42还用于, 当所述判断模块 44判断为是时, 向所述网络侧设 备发送文件修复请求;
所述接收模块 41还用于, 接收所述网络侧设备下发的指示消息, 并根据所 述指示消息接收所述网络侧设备重传的文件; 其中, 所述指示消息用于指示所述 终端设备在特定时间接收所请求重传的文件。
所述对终端设备请求业务密钥进行调度和控制的信息具体为:
指示终端设备在业务推送开始之前、 业务推送过程中、 或业务推送结束之 后发送业务密钥获取请求的信息。
所述对终端设备发起文件修复请求的行为进行调度和控制的信息具体为: 指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端设 备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丢失的数据量不超过门限的终 端设备向所述网络侧设备发送文件修复请求的信息以及门限值。 通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可 借助软件加必需的通用硬件平台的方式来实现, 当然也可以通过硬件,但很多情 况下前者是更佳的实施方式。基于这样的理解, 本发明的技术方案本质上或者说 对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品 存储在一个存储介质中, 包括若干指令用以使得一台计算机设备(可以是个人计 算机, 服务器, 或者网络设备等)执行本发明各个实施例所述的方法。
本领域技术人员可以理解附图只是一个优选实施例的示意图, 附图中 的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描 述分布于实施例的装置中, 也可以进行相应变化位于不同于本实施例的一 个或多个装置中。 上述实施例的模块可以合并为一个模块, 也可以进一步 拆分成多个子模块。
上述本发明实施例序号仅仅为了描述, 不代表实施例的优劣。 此, 任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims

权 利 要 求
1、 一种推送业务的实现方法, 其特征在于, 包括:
网络侧设备向终端设备下发推送业务的调度信息,以使所述终端设备根据 接收到的调度信息确定发送业务密钥获取请求的时间;其中所述调度信息包含 有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务密钥进行 调度和控制的信息;
当所述网络侧设备接收到终端设备发送的业务密钥获取请求时,网络侧设 备向所述终端设备发送业务密钥 ,以使所述终端设备根据所述业务密钥对接收 到的业务进行解密。
2、 如权利要求 1所述的方法, 其特征在于, 网络侧设备向终端设备下发 推送业务的调度信息, 具体为:
当网络侧设备接收到终端设备发送的调度信息获取请求时,所述网络侧设 备向所述终端设备下发推送业务的调度信息; 或,
3、 如权利要求 1所述的方法, 其特征在于, 所述调度信息中还包含有网 络侧设备推送的各个业务所包含的文件的标识和文件大小,以及用于对终端设 备发起文件修复请求的行为进行调度和控制的信息; 该方法还包括:
网络侧设备接收终端设备发送的文件修复请求,其中包含有终端设备的标 识, 以及该终端设备请求重传的文件的标识;
所述网络侧设备根据接收到的文件修复请求确定需要重传的文件,并向终 端设备发送指示消息, 指示相应终端设备在特定时间接收所请求重传的文件; 所述网络侧设备重传所确定的需要重传的文件。
4、 如权利要求 1-3任一项所述的方法, 其特征在于, 所述对终端设备请 求业务密钥进行调度和控制的信息具体为:
指示终端设备在业务推送开始之前、业务推送过程中或业务推送结束之后 发送业务密钥获取请求的信息。
5、 如权利要求 3所述的方法, 其特征在于, 所述对终端设备发起文件修 复请求的行为进行调度和控制的信息具体为:
指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端 设备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丟失的数据量不超过门限的 终端设备向所述网络侧设备发送文件修复请求的信息以及门限值。
6、 一种推送业务的实现方法, 其特征在于, 包括:
终端设备接收网络侧设备下发的推送业务的调度信息; 其中, 所述调度信 息中包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务 密钥进行调度和控制的信息;
所述终端设备根据接收到的调度信息确定获取业务密钥的时间,并根据该 时间向所述网络侧设备发送密钥获取请求;
所述终端设备根据获取到的业务密钥对所述网络侧设备推送的业务进行 解密。
7、 如权利要求 6所述的方法, 其特征在于, 所述终端设备接收网络侧设 备下发的推送业务的调度信息, 具体为: 所述终端设备向所述网络侧设备发送调度信息获取请求,并接收所述网络 侧设备下发的推送业务的调度信息; 或,
所述终端设备接收所述网络侧设备周期性下发的推送业务的调度信息。
8、 如权利要求 6所述的方法, 其特征在于, 所述调度信息中还包含有网 络侧设备推送的各个业务所包含的文件的标识和文件大小,以及用于对终端设 备发起文件修复请求的行为进行调度和控制的信息; 该方法还包括:
所述终端设备根据所述调度信息以及自身接收到的所述网络侧设备推送 的业务确定是否需要向所述网络侧设备发送文件修复请求, 并当判断为是时, 所述终端设备向所述网络侧设备发送文件修复请求;
所述终端设备接收所述网络侧设备下发的指示消息,该指示消息用于指示 所述终端设备在特定时间接收所请求重传的文件;
所述终端设备根据所述指示消息接收所述网络侧设备重传的文件。
9、 如权利要求 6-8任一项所述的方法, 其特征在于, 所述对终端设备请 求业务密钥进行调度和控制的信息具体为:
指示终端设备在业务推送开始之前、业务推送过程中或业务推送结束之后 发送业务密钥获取请求的信息。
10、 如权利要求 8所述的方法, 其特征在于, 所述对终端设备发起文件修 复请求的行为进行调度和控制的信息具体为:
指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端 设备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丟失的数据量不超过门限的 终端设备向所述网络侧设备发送文件修复请求的信息以及门限值。
11、 一种网络侧设备, 其特征在于, 包括:
第一发送模块, 用于向终端设备下发推送业务的调度信息, 以使所述终端 设备根据接收到的调度信息确定发送业务密钥获取请求的时间;其中所述调度 信息包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请求业务 密钥进行调度和控制的信息;
接收模块, 用于接收终端设备发送的业务密钥获取请求;
第二发送模块,用于当所述接收模块接收到终端设备发送的业务密钥获取 请求, 向所述终端设备发送业务密钥, 以使所述终端设备根据所述业务密钥对 接收到的业务进行解密。
12、 如权利要求 11所述的网络侧设备, 其特征在于,
所述第一发送模块具体用于,当所述接收模块接收到终端设备发送的调度 信息获取请求时, 向所述终端设备下发推送业务的调度信息; 或, 根据预设的 周期向终端设备下发推送业务的调度信息。
13、 如权利要求 11所述的网络侧设备, 其特征在于, 所述调度信息中还 包含有网络侧设备推送的各个业务所包含的文件的标识和文件大小,以及用于 对终端设备发起文件修复请求的行为进行调度和控制的信息;
所述接收模块还用于,接收终端设备发送的文件修复请求, 其中包含有终 端设备的标识, 以及该终端设备请求重传的文件的标识;
该网络侧设备还包括:
第三发送模块,用于根据接收模块接收到的文件修复请求确定需要重传的 文件, 并向终端设备发送指示消息,指示相应终端设备在特定时间接收所请求 重传的文件; 重传所确定的需要重传的文件。
14、 如权利要求 11-13任一项所述的网络侧设备, 其特征在于, 所述对终 端设备请求业务密钥进行调度和控制的信息具体为:
指示终端设备在业务推送开始之前、业务推送过程中或业务推送结束之后 发送业务密钥获取请求的信息。
15、 如权利要求 13所述的网络侧设备, 其特征在于, 所述对终端设备发 起文件修复请求的行为进行调度和控制的信息具体为:
指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端 设备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丟失的数据量不超过门限的 终端设备向所述网络侧设备发送文件修复请求的信息以及门限值。
16、 一种终端设备, 其特征在于, 包括:
接收模块, 用于接收网络侧设备下发的推送业务的调度信息; 其中, 所述 调度信息中包含有网络侧设备各个业务推送的时间点,以及用于对终端设备请 求业务密钥进行调度和控制的信息;
发送模块,用于根据所述接收模块接收到的调度信息确定获取业务密钥的 时间, 并根据该时间向所述网络侧设备发送密钥获取请求;
解密模块,用于根据获取到的密钥对接收到的所述网络侧设备推送的业务 进行解密。
17、 如权利要求 16所述的终端设备, 其特征在于,
所述接收模块具体用于,通过所述发送模块向所述网络侧设备发送调度信 息获取请求, 并接收所述网络侧设备下发的推送业务的调度信息; 或, 接收所 述网络侧设备周期性下发的推送业务的调度信息。
18、 如权利要求 16所述的终端设备, 其特征在于, 所述调度信息中还包 含有网络侧设备推送的各个业务所包含的文件的标识和文件大小,以及用于对 终端设备发起文件修复请求的行为进行调度和控制的信息; 所述终端设备还包括: 判断模块,用于根据所述调度信息以及所述接收模块接收到的网络侧设备 推送的业务确定是否需要向所述网络侧设备发送文件修复请求; 所述发送模块还用于, 当所述判断模块判断为是时, 向所述网络侧设备发 送文件修复请求; 所述接收模块还用于,接收所述网络侧设备下发的指示消息, 并根据所述 指示消息接收所述网络侧设备重传的文件; 其中, 所述指示消息用于指示所述 终端设备在特定时间接收所请求重传的文件。
19、 如权利要求 16-18任一项所述的终端设备, 其特征在于, 所述对终端 设备请求业务密钥进行调度和控制的信息具体为:
指示终端设备在业务推送开始之前、业务推送过程中或业务推送结束之后 发送业务密钥获取请求的信息。
20、 如权利要求 16-18任一项所述的终端设备, 其特征在于, 所述对终端 设备发起文件修复请求的行为进行调度和控制的信息具体为: 指示在接收网络侧设备推送的业务的过程中平均信噪比超过门限的终端 设备向所述网络侧设备发送文件修复请求的信息以及门限值; 或,
指示在接收网络侧设备推送的业务的过程中丟失的数据量不超过门限的 终端设备向所述网络侧设备发送文件修复请求的信息以及门限值。
PCT/CN2013/080106 2012-08-31 2013-07-25 一种推送业务的实现方法和设备 WO2014032489A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210317525.9A CN103685141B (zh) 2012-08-31 2012-08-31 一种推送业务的实现方法和设备
CN201210317525.9 2012-08-31

Publications (1)

Publication Number Publication Date
WO2014032489A1 true WO2014032489A1 (zh) 2014-03-06

Family

ID=50182460

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2013/080106 WO2014032489A1 (zh) 2012-08-31 2013-07-25 一种推送业务的实现方法和设备

Country Status (2)

Country Link
CN (1) CN103685141B (zh)
WO (1) WO2014032489A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103874024B (zh) * 2012-12-13 2017-06-20 中国移动通信集团公司 一种广播下载业务的任务调度方法、装置及系统
CN112398752B (zh) * 2020-11-16 2022-04-26 广州华多网络科技有限公司 消息推送控制方法及其装置、设备、介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060107287A1 (en) * 2002-08-15 2006-05-18 Kook-Heui Lee Multimedia broadcast/multicast service announcement and notification
CN101262626A (zh) * 2007-03-05 2008-09-10 大唐移动通信设备有限公司 Mbms的信道传输方法及系统、网络侧和终端
CN101296102A (zh) * 2007-04-27 2008-10-29 中兴通讯股份有限公司 多媒体广播组播业务调度方法及系统
CN101626568A (zh) * 2008-07-11 2010-01-13 中国移动通信集团公司 一种业务密钥的获取方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020138280A1 (en) * 2001-03-23 2002-09-26 Drabo David William Method and system for transcribing recorded information and delivering transcriptions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060107287A1 (en) * 2002-08-15 2006-05-18 Kook-Heui Lee Multimedia broadcast/multicast service announcement and notification
CN101262626A (zh) * 2007-03-05 2008-09-10 大唐移动通信设备有限公司 Mbms的信道传输方法及系统、网络侧和终端
CN101296102A (zh) * 2007-04-27 2008-10-29 中兴通讯股份有限公司 多媒体广播组播业务调度方法及系统
CN101626568A (zh) * 2008-07-11 2010-01-13 中国移动通信集团公司 一种业务密钥的获取方法及装置

Also Published As

Publication number Publication date
CN103685141A (zh) 2014-03-26
CN103685141B (zh) 2016-12-21

Similar Documents

Publication Publication Date Title
CN110169104B (zh) 具有组播和广播多媒体子系统能力的网络架构
CN101150595B (zh) 一种实时文件传输方法、系统及装置
CN106233815B (zh) 用于通过一个或多个流为一个或多个用户设备提供服务的系统及方法
WO2013178010A1 (zh) 一种多媒体内容分发方法、设备及系统
RU2011144153A (ru) Управление ключами безопасности в основанных на ims услугах широковещания и многоадресного вещания мультимедиа (mbms)
WO2010111812A1 (zh) 一种增强型多媒体广播组播服务中的数据重传方法及装置
CN103986764A (zh) 用于多客户端协同文件上传的设备和方法
WO2012083620A1 (zh) 一种流媒体文件的下载方法、装置及系统
CN107736039B (zh) 一种视频分发方法和设备
WO2010069134A1 (zh) 数据文件解密方法、解密装置和数据广播系统
WO2009021460A1 (fr) Procédé de rapport d'un résultat de mise en œuvre de politique, système de communication par réseau et équipement
KR20190099532A (ko) 미디어 다운링크 전송 제어 방법 및 관련 장치
CN111698289A (zh) 一种通信连接的控制方法、客户端设备及服务器
CN112738800A (zh) 一种网络切片的数据安全传输实现方法
CN112561103A (zh) 基于区块链的停车预约管理方法、节点、设备及介质
WO2012142790A1 (zh) 基于组播方式下载应用的方法、装置和系统
WO2014032489A1 (zh) 一种推送业务的实现方法和设备
WO2009039692A1 (fr) Procédé et système pour crypter une clé de flux de programme dans le service de diffusion multimédia mobile
WO2009015539A1 (fr) Procédé de commande multidiffusion pour service de demande de contenu multimédia et son système
WO2012130007A1 (zh) 一种mbms业务处理方法和系统
WO2014187091A1 (zh) 接入无线网络的方法及接入点
JP2008252364A (ja) 通信方法、通信システムおよび無線通信装置
WO2012094901A1 (zh) 超长短信发送/接收方法、装置及系统
WO2012016434A1 (zh) 一种鉴权参数的管理方法及终端
US20100042836A1 (en) Method for securely transmitting device management message via broadcast channel and server and terminal thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13832911

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13832911

Country of ref document: EP

Kind code of ref document: A1