WO2012152007A1 - 设备驱动消息处理方法及装置 - Google Patents

设备驱动消息处理方法及装置 Download PDF

Info

Publication number
WO2012152007A1
WO2012152007A1 PCT/CN2011/084297 CN2011084297W WO2012152007A1 WO 2012152007 A1 WO2012152007 A1 WO 2012152007A1 CN 2011084297 W CN2011084297 W CN 2011084297W WO 2012152007 A1 WO2012152007 A1 WO 2012152007A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
device driver
upper layer
interface
protocol
Prior art date
Application number
PCT/CN2011/084297
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 WO2012152007A1 publication Critical patent/WO2012152007A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Definitions

  • the present invention relates to the field of communications, and in particular to a device driven message processing method and apparatus.
  • BACKGROUND OF THE INVENTION Based on the global wireless chip format, different vendors are introducing different device driver specifications, for example, Qualcomm and Microsoft's main network driver interface spec (NDIS) + Qualcomm MSM Interface (Qualcomm MSM Interface)
  • NDIS main network driver interface spec
  • QMI Quant Comm MSM Interface
  • a device-driven message processing method including the steps of: transmitting a message to an upper layer corresponding to the upper layer protocol by using a first interface provided to an upper layer protocol;
  • the message is encapsulated according to a protocol supported by the device driver, and the message from the device driver is decapsulated into a message format supported by the upper layer protocol by using a protocol supported by the device driver;
  • the device-driven second interface transmits a message with the device driver, where the format of the message is a format of a protocol supported by the device driver.
  • the driving the message by using the second interface with the device includes, according to the device identifier, passing the second interface
  • the message carrying the device identifier is sent to the device driver corresponding to the device identifier.
  • the method further includes: performing state detection and management on the device driven by the device.
  • the device driver is a DIS device driver, and/or the upper layer protocol is RIL.
  • a device-driven message processing apparatus including: a first transmission module, configured to perform message transmission by an upper layer corresponding to the upper layer protocol by using a first interface provided to an upper layer protocol; a message processing module, configured to encapsulate a message from the upper layer protocol according to a protocol supported by the device driver, and decapsulate the message from the device driver into a protocol using a protocol supported by the device driver a message format supported by the upper layer protocol; the second transmission module is configured to transmit a message with the device driver by using the second interface provided to the device driver, where the format of the message is supported by the device driver The format of the agreement.
  • the second transmission module is configured to: when the message transmitted by the first interface carries the device identifier, the device identifier is carried by the second interface according to the device identifier. The message is sent to the device driver corresponding to the device identifier.
  • the method further includes: a device management module, configured to perform state detection and management on the device driven by the device.
  • the device driver is a DIS device driver, and/or the upper layer protocol is RIL.
  • the message is transmitted by the upper layer corresponding to the upper layer protocol by the first interface provided to the upper layer protocol; the message from the upper layer protocol is encapsulated according to the protocol supported by the device driver, and The device-driven message is decapsulated into a message format supported by the upper layer protocol according to a protocol supported by the device driver; and the device is driven to transmit a message by providing a second interface that is driven by the device,
  • the format of the message is the format of the protocol supported by the device driver, which solves the problem that the operating system has poor compatibility with the device driver in the prior art, and improves the compatibility of the operating system to the device driver.
  • FIG. 1 is a flowchart of a device driver message processing method according to an embodiment of the present invention
  • FIG. 2 is a structural block diagram of a device driver message processing device according to an embodiment of the present invention
  • FIG. 3 is a device driver of an Android system according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of a device-driven architecture of an Android system according to an embodiment of the present invention
  • FIG. 1 is a flowchart of a device driver message processing method according to an embodiment of the present invention
  • FIG. 2 is a structural block diagram of a device driver message processing device according to an embodiment of the present invention
  • FIG. 3 is a device driver of an Android system according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram of a device-driven architecture of an Android system according to an embodiment of the present invention
  • FIG. 5 is a flowchart of downlink data transmission according to an embodiment of the present invention
  • FIG. 6 is a flowchart according to an embodiment of the present invention.
  • BEST MODE FOR CARRYING OUT THE INVENTION BEST MODE FOR CARRYING OUT THE INVENTION
  • FIG. 1 is a flowchart of a device driving message processing method according to an embodiment of the present invention. As shown in FIG.
  • Step S102 by providing Sending a message to the upper layer corresponding to the upper layer protocol, and transmitting the message from the upper layer protocol according to the protocol supported by the device driver, and using the device from the device driver
  • the protocol supported by the driver decapsulates the message into a message format supported by the upper layer protocol.
  • Step S106 The device is driven to transmit a message by using the second interface provided to the device driver, where the format of the message is supported by the device driver. The format of the agreement. It should be noted that the above steps are not necessarily performed in the order of steps S102 to S106.
  • the device identifier can be set in the message transmitted by the first interface, in this case, through the second interface
  • the device driver transmits the message, and sends the message carrying the device identifier through the second interface according to the device identifier.
  • the device driver corresponding to the device ID.
  • the processing of multiple devices is also ported to the middle layer, without requiring any changes to the upper layer and device drivers, so that support for multiple device drivers is better.
  • the function of detecting and managing the status of the device accessed by the device driver can also be added in the middle layer.
  • Device drivers can be better controlled by the addition of these features.
  • the middle layer is located between a wireless broadband service layer (Radio Interface Layer, RIL) (ie, one of the upper layer protocols) and the device driver.
  • RIL Radio Interface Layer
  • a device access processing device is also provided, which is used to implement the foregoing embodiments and preferred embodiments, and has not been described again.
  • the term "module" may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus includes a first transmission module 22, a message processing module 24, and a second transmission module 26.
  • the module is explained.
  • the first transmission module 22 is configured to perform message transmission by using an upper layer corresponding to the upper layer protocol by using the first interface provided to the upper layer protocol;
  • the message processing module 24 is connected to the first transmission module 22, and the module is configured to be from the upper layer protocol.
  • the message is encapsulated according to a protocol supported by the device driver, and the message from the device driver is decapsulated into a message format supported by the upper layer protocol according to a protocol supported by the device driver; the second transmission module 26 is connected to the message.
  • the processing module 24 is configured to transmit a message with the device driver through a second interface provided to the device driver, wherein the format of the message is a format of a protocol supported by the device driver.
  • the second transmission module 22 is configured to: when the message transmitted through the first interface carries the device identifier, send, by the second interface, the message carrying the device identifier to the device identifier according to the device identifier.
  • Device driver Preferably, the apparatus may further include: a device management module configured to perform state detection and management on the device accessed through the device driver. A preferred embodiment will be described below with the Android system as an example, in conjunction with support for NDIS device drivers.
  • FIG. 3 is a first schematic diagram of a device driver architecture of an Android system according to an embodiment of the present invention. As shown in FIG.
  • the drive system includes a RIL framework, a QMI/AT framework, and a device driver module, where the QMI/AT framework includes The QmiClient module 304 (for implementing the functions of the first transmission module 22), the QmiDaemon module 302 (for implementing the functions of the second transmission module 26 and the message processing module 24), of course, in order to support the AT command, the AT command module can also be added. 301.
  • the QMI/AT framework implements the functions of the above intermediate layer.
  • 4 is a schematic diagram 2 of a device driver architecture of an Android system according to an embodiment of the present invention. As shown in FIG. 4, a message processing module 403 is added to the architecture. The message processing module and the QmiDaemon module implement the above message processing.
  • the QmiDaemon module 402 of Figure 4 has also been modified relative to the QmiDaemon module 302 of Figure 3, as explained below.
  • the QmiClient module 404 still provides a synchronous interface call to the upper layer. In addition to adding a device ID to the interface, the RIL layer interface is still maintained.
  • the message processing module 403 is mainly responsible for encapsulation and parsing of the message, wherein the message from the RIL layer is controlled by a wireless data service (QMI Wireless Data Service, referred to as WDS), QMI Control Service (QMI Control Service, CTL for short), QMI data management.
  • WDS wireless data service
  • QMI Control Service QMI Control Service
  • the message format (QMI Device Management Service, DMS for short) is used for data encapsulation, and the encapsulated message data is sent out through the socket mechanism.
  • the receiving is received by the receiving thread in the receiving thread waiting for data received from the socket. After the data is received, the received data is parsed, and the response of the request message is matched by the device ID, the message ID, and the like. For the actively reported message, only the device ID needs to be determined.
  • the QmiDaemon module 402 is mainly responsible for message management, asynchronous sending and receiving; message management refers to receiving a message sent by the message processing module through the socket, and then placing the message on the corresponding device according to the device ID corresponding to the message. In the send message queue; the receiving thread is responsible for receiving data read from the device, and placing the received data in the receive queue.
  • the NDIS device management module 405 is mainly responsible for node management, state management, and the like of multiple DIS devices.
  • the driving method and system provided by the above preferred embodiments have the following advantages: (1) Added support for multiple DIS devices, enabling the Android system to support multiple DIS devices at the same time, changing and expanding the situation that the RIL driver part of the existing Android system can only operate one device, so that the RIL driver part can be increased. Support for multiple DIS devices, while the interface above the RIL layer remains unchanged, solving the problem that the Android system cannot currently support multiple NDIS devices.
  • the preferred embodiment integrates the management and access modes of multiple NDIS devices into the existing RIL framework of the Android system, without modifying the architecture of the Android system RIL and Framwork, and increasing the access mode of the Android system to the mobile broadband device.
  • NDIS equipment is one of the mainstream access methods for mobile broadband devices. It can support multiple DIS devices (such as NDIS devices of different standards) on one system, which greatly complies with the access of multiple multi-standard and multi-PDP devices.
  • the QMIClient module still uses the synchronous API method for the interface provided by the upper layer, which is compatible with the previous solution, so that the upper layer is The interface call of the QMI Client can be used without much modification, which greatly improves the versatility of the technical solution.
  • the module in Fig. 4 above will be described in detail below.
  • QmiDaemon module 402 this module can be completed by the following three threads:
  • the Qmi message receiving thread is used to detect whether there is a message to be processed in the sending message queue.
  • the device operation interface encapsulated by the DIS device management module is called, and the message is sent to the corresponding NDIS device. If the sending is successful, the message mailbox is sent. (mail box) sends a signal to the response message processing thread, informing it to send an ack ok message to the message processing module, otherwise sending an ack error message; the response message is waiting for a return value from the NDIS device; if it is a custom message type, directly Processing, after the processing is completed, first send an ack ok or ack error message, and then directly send the response message content to the socket to send the result to the message processing module.
  • the NDIS device data receiving thread is used to detect whether data from the DIS device needs to be processed, and then the received message and the device ID are encapsulated into a predefined format, and then placed in the receiving message queue, and simultaneously through the message mailbox (Mail box) sends a signal to the response message processing thread, informing it to send a response message to the message processing module, otherwise it continues the loop detection.
  • the response message processing thread waits for the signal sent by the Qmi message receiving thread and the NDIS device data receiving thread to be processed according to the signal type: if it is an ack message, it needs to match the corresponding message according to the parameter (device ID and message ID) carried in the signal.
  • the request then encapsulates the ACK message, and sends the message to the message processing module through the socket; if it is a response message, it also needs to match the corresponding message request according to the device ID and the message ID, and then encapsulates the response message, and sends a message to the message processing module through the socket. If it is an actively reported message, it only matches the device ID, then encapsulates the message that is actively reported, and sends a message to the message processing module through the socket.
  • the message processing module 403 is configured to encapsulate and parse the message; the first is to encapsulate the message from the QmiClient module into a corresponding QMI instruction according to different content, for example, NDIS packet data in a format such as WDS, CTL, DMS, and the like, and through the socket.
  • the information such as the device ID and the message ID matches the response of the request message, and then returns the response data to the QmiClient module. For the actively reported message, only the device ID needs to be determined.
  • QmiClient module 404 This module is mainly responsible for providing a synchronous application program interface (API) function to the upper layer, so that QMI and RIL can be seamlessly connected.
  • API application program interface
  • the interface of the RIL layer does not need the device ID.
  • the RIL layer interface needs to increase the device ID, used to identify the operation of different devices, so the device ID is added in the API parameters provided here; Consistency and compatibility with the previous interface, the function and service of the interface are basically the same as those of the original system.
  • Device Management Module 405 This module mainly handles the status detection and management of the device: First, it responds to the hot plugging of the device: Responsible for device registration, device node registration, device queue maintenance, and number initialization; After the device is removed, the maintenance of the device node queue, the cleaning of the device status information, etc.; the second is the encapsulation of the device operation API, such as opening, closing, reading, writing, etc., these operation interfaces are similar to the operation of the file; Maintenance of the device status during abnormal operation such as maintenance, device pull-out, etc. The transmission of the uplink data and the downlink data will be separately described below with reference to FIG.
  • FIG. 5 is a flowchart of downlink data transmission according to an embodiment of the present invention. As shown in FIG.
  • Step S501 The RIL layer receives various function calls of the Android system; Step S502, according to different services. Type, call the interface corresponding to the QmiClient module; Step S503, determine the type of the message, if it is CTL related, then go to step S504; if it is WDS related, then go to step S505; if it is DMS related, then go to step S506; Step S504, encapsulating the corresponding CTL message according to the format of the CTL message, after the encapsulation is completed, proceeding to step S507; Step S505, encapsulating the corresponding WDS message according to the format of the WDS message, after the encapsulation is completed, proceeding to step S507; Step S506 According to the format of the DMS message, the corresponding DMS message is encapsulated.
  • Step S507 the message processing module sends the encapsulated data through the socket mechanism.
  • Step S508 the QmiDaemon module receives the message from the socket.
  • step S509 the maintenance of the message queue is processed;
  • Step S510 the device management mode When the block detects that the message queue has a message to be processed, the device operates on the device operation interface.
  • FIG. 6 is a flowchart of uplink data transmission according to an embodiment of the present invention. As shown in FIG. 6, the process includes the following steps: Step S601: Using a thread mechanism, starting a device data read thread.
  • Step S602 looping to determine whether the device has data, if there is data, proceeding to step S603, otherwise continuing to wait and detecting the message.
  • Step S603 the received data is encapsulated into a fixed message format in advance, and then put into the message queue.
  • Step S604 using a thread mechanism, pre-launching the Qmi message receiving thread.
  • Step S605 iteratively determines whether there is data in the received message queue, and if so, proceeds to step S606, otherwise continues to wait and detects the message.
  • Step S607 the parsed message is sent by using a socket mechanism.
  • Step S608 using a thread mechanism, pre-launching the socket message receiving thread.
  • Step S609 in the socket detection thread, cyclically detecting whether there is a socket message, if yes, proceeding to step S610, otherwise continuing to wait and detecting the message.
  • Step S610 parsing the socket message.
  • Step S611 returning the parsed data to the RIL layer interface.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了设备驱动消息处理方法及装置，该方法包括如下步骤：通过提供给上层协议的第一接口，与上层协议对应的上层进行消息的传输；将来自上层协议的消息按照设备驱动所支持的协议进行封装，并且，将来自设备驱动的消息使用设备驱动所支持的协议将该消息解封装为上层协议所支持的消息格式；通过提供给设备驱动的第二接口，与设备驱动传输消息，其中，该消息的格式为设备驱动所支持的协议的格式。通过本发明提高了操作系统对设备驱动的兼容性。

Description

设备驱动消息处理方法及装置 技术领域 本发明涉及通信领域， 具体而言， 涉及一种设备驱动消息处理方法及装置。 背景技术 基于全球无线芯片的格局， 不同的厂商均在推出不同的设备驱动规范， 例如， 高 通和微软主推的网络驱动接口规范 （network driver interface spec, 简称为 NDIS) +高 通 MSM接口 （Qualcomm MSM Interface, 简称为 QMI) 的移动宽带设备高速接入方 案成为当下移动宽带设备的主流接入方式之一； 但 NDIS+QMI的方式目前在 windows 系统上得到了应用， 并且， 对于其他的系统， 随着技术的不断发展， 逐步的也可以支 持该规范。 同时， 对于操作系统而言， 其也在不断推新， 一方面， 现有的操作系统在不停的 发展以适应不同的终端类型， 另一方面， 也出现了其他类型的新的操作系统， 例如， 安卓 Android移动操作系统。 由上述现有的技术发展的趋势可以看出， 操作系统与设备驱动规范的发展并不是 统一的， 这样， 操作系统需要支持原来越多的设备驱动， 对于不同的设备驱动， 在操 作系统上均需要编写对应的与上层应用对接的中间层代码。 即在现有技术中， 操作系 统对设备驱动的兼容性比较差。 发明内容 本发明提供了一种设备驱动消息处理方法及装置， 以至少解决上述问题。 根据本发明的一方面， 提供了一种设备驱动消息处理方法， 包括如下步骤： 通过 提供给上层协议的第一接口， 与所述上层协议对应的上层进行消息的传输； 将来自所 述上层协议的消息按照设备驱动所支持的协议进行封装， 并且， 将来自所述设备驱动 的消息使用所述设备驱动所支持的协议将该消息解封装为所述上层协议所支持的消息 格式； 通过提供给所述设备驱动的第二接口， 与所述设备驱动传输消息， 其中， 该消 息的格式为所述设备驱动所支持的协议的格式。 优选地， 在通过所述第一接口进行传输的消息中携带有设备标识的情况下， 通过 所述第二接口与所述设备驱动传输消息包括， 根据所述设备标识通过所述第二接口将 携带有该设备标识的消息发送给与所述设备标识对应的设备驱动。 优选地， 还包括： 对通过所述设备驱动接入的设备进行状态检测和管理。 优选地， 所述设备驱动为 DIS设备驱动， 和 /或， 所述上层协议为 RIL。 根据本发明的另一方面， 提供了一种设备驱动消息处理装置， 包括： 第一传输模 块， 设置为通过提供给上层协议的第一接口， 与所述上层协议对应的上层进行消息的 传输； 消息处理模块， 设置为将来自所述上层协议的消息按照设备驱动所支持的协议 进行封装， 并且， 将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消 息解封装为所述上层协议所支持的消息格式； 第二传输模块， 设置为通过提供给所述 设备驱动的第二接口， 与所述设备驱动传输消息， 其中， 该消息的格式为所述设备驱 动所支持的协议的格式。 优选地， 所述第二传输模块， 设置为在通过所述第一接口进行传输的消息中携带 有设备标识的情况下， 根据所述设备标识通过所述第二接口将携带有该设备标识的消 息发送给与所述设备标识对应的设备驱动。 优选地， 还包括： 设备管理模块， 设置为对通过所述设备驱动接入的设备进行状 态检测和管理。 优选地， 所述设备驱动为 DIS设备驱动， 和 /或， 所述上层协议为 RIL。 通过本发明， 通过提供给上层协议的第一接口， 与所述上层协议对应的上层进行 消息的传输； 将来自所述上层协议的消息按照设备驱动所支持的协议进行封装， 并且， 将来自所述设备驱动的消息按照所述设备驱动所支持的协议将该消息解封装为所述上 层协议所支持的消息格式； 通过提供给所述设备驱动的第二接口， 与所述设备驱动传 输消息， 其中， 该消息的格式为所述设备驱动所支持的协议的格式， 解决了现有技术 中操作系统对设备驱动的兼容性比较差问题， 提高了操作系统对设备驱动的兼容性。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中： 图 1是根据本发明实施例的设备驱动消息处理方法的流程图； 图 2是根据本发明实施例的设备驱动消息处理装置的结构框图； 图 3是根据本发明实施例的 Android系统的设备驱动的架构的示意图一； 图 4是根据本发明实施例的 Android系统的设备驱动的架构的示意图二； 图 5是根据本发明实施例的下行数据传输的流程图； 图 6是根据本发明实施例的上行数据传输的流程图。 具体实施方式 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突的 情况下， 本申请中的实施例及实施例中的特征可以相互组合。 在本实施例中提供了一种设备驱动消息处理方法， 图 1是根据本发明实施例的设 备驱动消息处理方法的流程图， 如图 1所示， 该流程包括如下步骤： 步骤 S102, 通过提供给上层协议的第一接口， 与上层协议所对应的上层进行消息 的传输； 步骤 S104,将来自该上层协议的消息按照设备驱动所支持的协议进行封装，并且， 将来自设备驱动的消息使用设备驱动所支持的协议将该消息解封装为上层协议所支持 的消息格式； 步骤 S106, 通过提供给设备驱动的第二接口， 与设备驱动传输消息， 其中， 该消 息的格式为设备驱动所支持的协议的格式。 需要说明的是， 上述的步骤不一定按照步骤 S102至步骤 S106的顺序执行。 通过 上述步骤，提供了在设备驱动层和上层协议之间提供了一种中间层的处理方式，这样， 对于不同的驱动程序不需要再重新开发中间层的驱动， 从而提高了操作系统对设备驱 动的兼容性。 为了同时支持多个设备驱动（例如， 多个同类型的设备驱动）， 在一个优选实施方 式中， 可以在第一接口传输的消息中设置设备标识， 在这种情况下， 通过第二接口与 设备驱动传输消息包括； 根据设备标识通过第二接口将携带有该设备标识的消息发送 给与设备标识对应的设备驱动。 通过该优选的实施方式， 将对多个设备的处理也移植 到中间层中， 不需要上层和设备驱动进行任何的改动， 使对多个设备驱动的支持更好。 优选地， 在该中间层中还可以增加对通过设备驱动接入的设备进行状态检测和管 理的功能。 通过这些功能的增加可以更好的对设备驱动进行控制。 在目前的 Android系统 （安卓系统） 中， 并没有提供能够对多个 DIS设备驱动 的支持， 上述实施例及优选的实施方式可以应用在安卓系统中， 在该系统中为了较小 的改动系统架构， 上述的中间层位于无线宽带业务处理（无线接口层）（Radio Interface Layer,简称为 RIL) (即上层协议中的一种）和设备驱动之间。这样可以实现与 Android 系统现有 RIL驱动的无缝对接，从而既能实现对多 DIS设备的无缝接入，提高 Android 系统的对多 DIS设备支持的缺陷，扩展了 Android系统的功能，提供了 Android系统 更为丰富的宽带设备接入， 又能较少的修改 Android系统框架。 在本实施例中还提供了一种设备接入处理装置， 该装置用于实现上述实施例及优 选实施方式， 已经进行过说明的不再赘述。 如以下所使用的， 术语 "模块"可以实现 预定功能的软件和 /或硬件的组合。 尽管以下实施例所描述的装置较佳地以软件来实 现， 但是硬件， 或者软件和硬件的组合的实现也是可能并被构想的。 图 2是根据本发 明实施例的设备驱动消息处理装置的结构框图， 如图 2所示， 该装置包括第一传输模 块 22、 消息处理模块 24和第二传输模块 26， 下面对该装置涉及的模块进行说明。 第一传输模块 22， 设置为通过提供给上层协议的第一接口， 与上层协议对应的上 层进行消息的传输； 消息处理模块 24， 连接至第一传输模块 22， 该模块设置为将来自 上层协议的消息按照设备驱动所支持的协议进行封装， 并且， 将来自设备驱动的消息 按照设备驱动所支持的协议将该消息解封装为上层协议所支持的消息格式； 第二传输 模块 26， 连接至消息处理模块 24， 该模块设置为通过提供给设备驱动的第二接口， 与 设备驱动传输消息， 其中， 该消息的格式为设备驱动所支持的协议的格式。 优选地， 第二传输模块 22， 设置为在通过第一接口进行传输的消息中携带有设备 标识的情况下， 根据设备标识通过第二接口将携带有该设备标识的消息发送给与设备 标识对应的设备驱动。 优选地， 该装置还可以包括： 设备管理模块， 该模块设置为对通过设备驱动接入 的设备进行状态检测和管理。 下面以安卓系统为例，结合对 NDIS设备驱动的支持对一个优选实施例进行说明。 在优选实施例中， 对于安卓系统如何支持 NDIS单设备驱动并不是讨论的重点， 而重点在于如何提供一个中间层的处理方式， 以及如何支持多个 DIS设备。 对于安 卓系统如何支持 NDIS设备可以采用不同的方式来进行， 其并不影响本优选实施例的 实施， 在此不再赘述。 本优选实施例可以对多 DIS设备进行支持， 实现了与 Android 系统现有 RIL驱动的无缝对接。 图 3是根据本发明实施例的 Android系统的设备驱动的架构的示意图一， 如图 3 所示， 该驱动系统包括 RIL框架、 QMI/AT框架和设备驱动模块， 其中， 该 QMI/AT 框架包括 QmiClient模块 304 (用于实现第一传输模块 22的功能）、 QmiDaemon模块 302 (用于实现第二传输模块 26和消息处理模块 24的功能）， 当然， 为了支持 AT命 令， 还可以增加 AT命令模块 301。 该 QMI/AT框架实现了上述中间层的功能。 图 4是根据本发明实施例的 Android系统的设备驱动的架构的示意图二， 如图 4 所示， 在该架构中增加了消息处理模块 403 (该消息处理模块和 QmiDaemon模块结合 实现了上述消息处理模块 24的功能） 和设备管理模块 405。 图 4中的 QmiDaemon模 块 402相对于图 3中的 QmiDaemon模块 302也进行了修改， 下面对此进行说明。 QmiClient模块 404， 依旧提供同步的接口调用给上层使用， 除了在接口中增加了 设备 ID外、 依旧保持了 RIL层接口的统一性。 消息处理模块 403， 主要负责消息的封装和解析， 其中对来自 RIL层消息按无线 数据服务 （QMI Wireless Data Service, 简称为 WDS)、 QMI控制服务 （QMI Control Service, 简称为 CTL)、 QMI数据管理服务（QMI Device Management Service, 简称为 DMS)等消息格式进行数据封装， 并将封装好的消息数据，通过 socket机制发送出去， 接收则通过在接收线程中等待从 socket收到的数据， 接收线程收到数据后， 解析接收 到数据， 并通过设备 ID、 消息 ID等信息匹配是哪个请求消息的响应， 对于主动上报 的消息， 则只需要确定设备 ID即可。
QmiDaemon模块 402， 主要负责消息的管理， 异步发送和接收； 消息的管理是指 要接收来自消息处理模块通过 socket发送过来的消息，之后根据消息所对应的设备 ID， 将该消息放到对应设备的发送消息队列中； 接收线程中负责接收从设备读取的数据， 并将接收到数据放在接收队列中。
NDIS设备管理模块 405， 主要负责多个 DIS设备的节点管理， 状态管理等。 上述优选实施例提供的驱动方法及系统， 具有以下优点： ( 1 )增加了对多个 DIS设备的支持，使得 Android系统可以同时支持多个 DIS 设备， 改变和扩展了现有 Android系统中 RIL驱动部分只能操作一个设备的情况， 使 得 RIL驱动部分可以增加对多个 DIS设备的支持、 而 RIL层之上的接口依旧保持不 变， 解决了 Android系统目前无法支持多个 NDIS设备的问题。 本优选实施例是将多 NDIS设备的管理和接入方式融入到 Android系统现有的 RIL框架中，没有修改 Android 系统 RIL和 Framwork的架构， 增加了 Android系统对移动宽带设备的接入方式增加 了 Android系统的扩展性； 在 QmiDaemon模块中增加了对自定义消息处理的逻辑、使 得本技术方案在 Qmi协议之外可以增加对私有协议的支持， 增强了 Android系统的扩 展性。 (2) NDIS设备作为后续移动宽带设备主流接入方式之一， 可以一个系统上同时 支持多个 DIS设备（例如不同制式的 NDIS设备），极大地符合了后续多制式、多 PDP 设备的接入方式和技术的发展趋势， 扩展了 Android系统的功能， 使得 Android系统 有了更大的通用性，同时 QMIClient模块对上层提供的接口依旧才用同步 API的方式， 兼容了以前的方案， 使得上层对 QMI Client的接口调用， 不需要做过多的修改即可使 用， 大大的提高了本技术方案的通用性。 下面上述图 4中的模块进行详细的说明。
QmiDaemon模块 402， 该模块可以通过如下三个线程完成：
Qmi消息接收线程
Qmi消息接收线程用于检测发送消息队列是否有消息需要处理， 有则在此线程中 调用 DIS设备管理模块封装的设备操作接口， 将消息发送到对应的 NDIS设备， 如 果发送成功， 则通过消息邮箱（mail box)发送信号给响应消息处理线程， 通知它发送 ack ok的消息给消息处理模块， 否则发送 ack error消息； response消息则等待从 NDIS 设备的返回值； 如果是自定义消息类型， 则直接处理， 处理完成后， 首先发送 ack ok 或者 ack error的消息， 然后直接发送 response的消息内容给通过 socket将结果发送给 消息处理模块。
NDIS设备数据接收线程
NDIS设备数据接收线程用于检测是否有从 DIS设备来的数据需要处理，有则将 接收到的消息和设备 ID—起封装成预定义的格式，然后放进接收消息队列， 同时通过 消息邮箱（mail box)发送信号给响应消息处理线程， 通知它发送响应（Response) 消 息给消息处理模块， 否则继续循环检测。 响应消息处理线程 等待 Qmi消息接收线程和 NDIS设备数据接收线程发送过来的信号， 根据信号类 型分别处理： 如果是 ack消息， 则需要根据信号中携带的参数 （设备 ID和消息 ID) 匹配对应的消息请求， 然后封装 ACK消息， 并通过 socket发送消息给消息处理模块； 如果是 response消息， 同样需要根据设备 ID和消息 ID匹配对应的消息请求， 然后封 装 response消息， 并通过 socket发送消息给消息处理模块； 如果是主动上报的消息， 仅仅匹配设备 ID，然后封装主动上报的消息，并通过 socket发送消息给消息处理模块。 消息处理模块 403 该模块用来封装和解析消息； 一是将来自 QmiClient模块的消息根据内容的不同 封装成为对应的 QMI指令， 例如， WDS、 CTL、 DMS等格式的 NDIS报文数据， 并 通过 socket发送给 QmiDaemon模块； 二是启动消息接收线程， 通过 socket接收来自 QmiDaemon模块的 ACK消息、 response消息和主动上报等响应消息； 针对 response 消息需要根据 WDS、 CTL、 DMS等格式解析响应消息内容， 并通过设备 ID、 消息 ID 等信息匹配是哪个请求消息的响应， 然后返回响应数据给 QmiClient模块， 对于主动 上报的消息， 则只需要确定设备 ID即可。
QmiClient模块 404 该模块主要负责提供同步的应用程序接口 （Application Program Interface, 简称为 API) 函数给上层调用， 使得 QMI和 RIL可以无缝对接； 原有系统中， RIL层的接口 不需要设备 ID即可直接发送消息和接收响应， 现在有了多设备的管理， RIL层的接口 需要增加设备 ID， 用来标识对不同设备的操作， 因此在这里提供的 API参数中增加了 设备 ID; 同时为了保持和以前接口的一致性和兼容性， 接口的功能和业务上和原有系 统基本保持一致， 仅仅增加了 NDIS设备特有的一些接口定义， 例如： 获取网络接口 名称（qmi_get_network_interface_name)、网络连接时常 ( qmi_get_conn_duration) DIS 设备侧 profile获取 （qmi_profile_get) 等。 设备管理模块 405 该模块主要处理对于设备的状态检测和管理： 一是对设备的热插拔做出响应： 负 责设备插入后， 设备节点的注册和设备队列的维护， 以及号量的初始化等； 设备拔出 后， 设备节点队列的维护， 设备状态信息的清理等； 二是对设备操作 API的封装， 如 打开、 关闭、 读、 写等， 这些操作接口类似于文件的操作； 三是设备状态的维护， 设 备拔出等异常操作时， 设备状态的维护。 下面结合图 4对上行数据和下行数据的传输分别进行说明。 图 5是根据本发明实施例的下行数据传输的流程图， 如图 5所示， 该流程包括如 下步骤： 步骤 S501， RIL层接收到 Android系统的各种功能调用； 步骤 S502, 根据不同的业务类型， 调用 QmiClient模块对应的接口； 步骤 S503 , 判断消息的类型， 如果是 CTL相关， 则转往步骤 S504; 如果是 WDS 相关， 则转往步骤 S505; 如果是 DMS相关， 则转往步骤 S506; 步骤 S504, 根据 CTL消息的格式， 封装对应的 CTL消息， 封装完成后， 转往步 骤 S507; 步骤 S505， 根据 WDS消息的格式， 封装对应的 WDS消息， 封装完成后， 转往 步骤 S507; 步骤 S506， 根据 DMS消息的格式， 封装对应的 DMS消息， 封装完成后， 转往 步骤 S507; 步骤 S507, 消息处理模块通过 socket机制将封装好的数据发送出去； 步骤 S508， QmiDaemon模块接收来自 sokcet的消息，收到消息后转往步骤 S509; 步骤 S509, 处理消息队列的维护； 步骤 S510, 设备管理模块检测到消息队列有需要处理的消息， 则通过设备操作接 口对设备进行操作。 图 6是根据本发明实施例的上行数据传输的流程图， 如图 6所示， 该流程包括如 下步骤： 步骤 S601 , 采用线程机制， 启动设备数据读取线程。 步骤 S602, 循环判断设备是否有数据， 如果有数据则转入步骤 S603处理， 否则 继续等待并检测消息。 步骤 S603 , 预先将收到的数据封装成固定的消息格式， 然后放进消息队列。 步骤 S604, 采用线程机制， 预先启动 Qmi消息接收线程。 步骤 S605， 循环判断接收消息队列是否有数据， 如果有， 则转入步骤 S606处理， 否则继续等待并检测消息。 步骤 S606, 解析从消息队列获取的消息。 步骤 S607, 将解析后的消息通过 socket机制发送。 步骤 S608, 采用线程机制， 预先启动 socket消息接收线程。 步骤 S609, 在 socket检测线程中， 循环检测是否有 socket消息， 如果有， 则转入 步骤 S610处理， 否则继续等待并检测消息。 步骤 S610, 解析 socket消息。 步骤 S611 , 将解析后的数据返回给 RIL层接口。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所 组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而可以将 它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。 这样， 本发明不限 制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的 任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1. 一种设备驱动消息处理方法， 包括如下步骤：
通过提供给上层协议的第一接口， 与所述上层协议对应的上层进行消息的 传输；
将来自所述上层协议的消息按照设备驱动所支持的协议进行封装， 并且， 将来自所述设备驱动的消息使用所述设备驱动所支持的协议将该消息解封装为 所述上层协议所支持的消息格式；
通过提供给所述设备驱动的第二接口， 与所述设备驱动传输消息， 其中， 该消息的格式为所述设备驱动所支持的协议的格式。
2. 根据权利要求 1所述的方法， 其中， 在通过所述第一接口进行传输的消息中携 带有设备标识的情况下， 通过所述第二接口与所述设备驱动传输消息包括， 根据所述设备标识通过所述第二接口将携带有该设备标识的消息发送给与 所述设备标识对应的设备驱动。
3. 根据权利要求 1所述的方法， 其中， 还包括： 对通过所述设备驱动接入的设备 进行状态检测和管理。
4. 根据权利要求 1至 3中任一项所述的方法， 其中， 所述设备驱动为 DIS设备 驱动， 和 /或， 所述上层协议为无线接口层协议 RIL。
5. 一种设备驱动消息处理装置， 包括：
第一传输模块， 设置为通过提供给上层协议的第一接口， 与所述上层协议 对应的上层进行消息的传输；
消息处理模块， 设置为将来自所述上层协议的消息按照设备驱动所支持的 协议进行封装， 并且， 将来自所述设备驱动的消息使用所述设备驱动所支持的 协议将该消息解封装为所述上层协议所支持的消息格式；
第二传输模块， 设置为通过提供给所述设备驱动的第二接口， 与所述设备 驱动传输消息， 其中， 该消息的格式为所述设备驱动所支持的协议的格式。
6. 根据权利要求 5所述的装置， 其中， 所述第二传输模块， 设置为在通过所述第 一接口进行传输的消息中携带有设备标识的情况下， 根据所述设备标识通过所 述第二接口将携带有该设备标识的消息发送给与所述设备标识对应的设备驱 动。
7. 根据权利要求 5所述的装置， 其中， 还包括： 设备管理模块， 设置为对通过所 述设备驱动接入的设备进行状态检测和管理。
8. 根据权利要求 5至 7中任一项所述的装置， 其中， 所述设备驱动为 DIS设备 驱动， 和 /或， 所述上层协议为无线接口层协议 RIL。
PCT/CN2011/084297 2011-08-17 2011-12-20 设备驱动消息处理方法及装置 WO2012152007A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110235881.1 2011-08-17
CN201110235881.1A CN102360307A (zh) 2011-08-17 2011-08-17 设备驱动消息处理方法及装置

Publications (1)

Publication Number Publication Date
WO2012152007A1 true WO2012152007A1 (zh) 2012-11-15

Family

ID=45585639

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/084297 WO2012152007A1 (zh) 2011-08-17 2011-12-20 设备驱动消息处理方法及装置

Country Status (2)

Country Link
CN (1) CN102360307A (zh)
WO (1) WO2012152007A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102707997B (zh) 2012-06-12 2014-06-11 中兴通讯股份有限公司 一种移动宽带设备多pdp数据通讯的驱动装置和方法
CN104679596A (zh) * 2013-12-02 2015-06-03 航天信息股份有限公司 一种提高服务器端并发性能的消息处理方法及其系统
CN106209809B (zh) * 2016-07-01 2019-07-05 上海畅联智融通讯科技有限公司 基于安卓系统的AP与Modem的通信系统
CN108089927B (zh) * 2016-11-23 2022-01-14 阿里巴巴集团控股有限公司 基于Web Worker实现消息通信的方法以及装置
CN106802869B (zh) * 2017-01-17 2020-03-20 东方网力科技股份有限公司 类串口设备的驱动方法及驱动系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1446425A (zh) * 2000-04-24 2003-10-01 微软公司 在无线射频介质上提供远程网络驱动器接口规范服务
CN101977244A (zh) * 2010-09-21 2011-02-16 华为终端有限公司 一种控制方法、装置和系统
CN102023862A (zh) * 2010-12-13 2011-04-20 中兴通讯股份有限公司 一种移动终端控制方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1446425A (zh) * 2000-04-24 2003-10-01 微软公司 在无线射频介质上提供远程网络驱动器接口规范服务
CN101977244A (zh) * 2010-09-21 2011-02-16 华为终端有限公司 一种控制方法、装置和系统
CN102023862A (zh) * 2010-12-13 2011-04-20 中兴通讯股份有限公司 一种移动终端控制方法及系统

Also Published As

Publication number Publication date
CN102360307A (zh) 2012-02-22

Similar Documents

Publication Publication Date Title
US9760517B2 (en) Network-USB (NUSB) communication system by which network applications communicate with USB devices over power-over-ethernet (PoE) connection
US8743903B2 (en) Hybrid networking simple-connect setup using forwarding device
WO2019019906A1 (zh) 一种通信方法、设备及存储介质
CN101542980B (zh) 用于操作兼容以太网的现场总线设备的方法
EP2416508A2 (en) Synchronization for data transfer between physical layers
WO2009133432A1 (en) Methods, devices, and computer program products for remotely controlling operations of digital media devices using a mobile terminal
WO2012152007A1 (zh) 设备驱动消息处理方法及装置
WO2012097756A2 (zh) 一种电力网关及电力网关的通信方法
WO2014186179A1 (en) Media time based usb frame counter synchronization for wi-fi serial bus
US9635711B1 (en) Mobile broadband management over plurality of operating systems and media
WO2013071709A1 (zh) 支持以3G及Wi-Fi方式接入网络的无线宽带数据卡
WO2010145091A1 (zh) 一种虚拟网口的实现方法及实现虚拟网口的嵌入式设备
US20180131609A1 (en) Protocol frame transmission method, apparatus, and system, and node device
EP2445160B1 (en) Method for automatically negotiating type of service and aggregation apparatus therefor
WO2012151998A1 (zh) 移动宽带设备的数据处理方法及驱动装置
BRPI0207277B1 (pt) método para manter e aplicar, de forma seletiva, compressão ppp em um sistema de comunicação sem fio
EP2466814A1 (en) Method, remote access server and system for configuring quality of service
WO2022007749A1 (zh) 一种数据传输方法和装置
JP5711688B2 (ja) 通信装置及びプログラム
CN110620999B (zh) 用户面数据处理方法及装置
WO2012155517A1 (zh) 终端扩展装置、系统及方法
WO2012019376A1 (zh) 无线通信终端网络设备功能的实现方法及装置
WO2019140648A1 (zh) 一种终端上报信息的方法及装置、计算机存储介质
WO2013178173A1 (zh) 数据卡类终端的工作模式确定方法、装置及系统
WO2023040350A1 (zh) 云端与物联网设备间的通信方法、装置、介质及产品

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: 11865198

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: 11865198

Country of ref document: EP

Kind code of ref document: A1