高通拨号流程介绍
高通拨号流程介绍
-
1 简介
-
2 APPS与MODEM间数据传输
-
- 2.1 APPS与MODEM间数据通路
- 2.2 物理数据通道及数据传输格式
- 2.3 QMAP协议
- 2.4 APPS侧数据流程相关代码分析
-
- 2.4.1 虚拟网络接口的创建
- 2.4.2 物理网络接口数据接收流程
- 2.4.3 虚拟网络接口数据发送流程
-
3 dsi_netctrl_test数据拨号
-
- 3.1 dsi_netctrl_test数据拨号流程
- 3.2 netmgr配置虚拟网络接口
1 简介
高通平台如sdx55内部包含多个处理器，其中APSS使用的是Arm Cortex-A7处理器，MODEM侧使用的是高通的Q6处理器。那AP和modem之间的数据通路是如何建立的呢？
dsi_netctrl_test是在APPS内部的可执行程序，该程序从APPS发起数据拨号流程，建立APPS与MODEM之间的数据通路。拨号成功后，APPS内部的应用程序数据可以经由该数据通路到达MODEM，进而经由无线接口访问外部网络。
下面是整体框图：
sdx55内部A7处理器与Q6处理器之间的控制和数据通路参考上图。外部数据可以多种接口方式接入到A7，如USB接口、PCIe接口及以太网接口。A7与Q6之间的数据经由IPA模块(IP硬件加速)直接传输。数据到达Q6之后，经由无线接口访问外部网络。
A7与Q6之间的控制消息通过共享内存通道进行传输。
2 APPS与MODEM间数据传输
2.1 APPS与MODEM间数据通路
上图为dsi_netctrl_test程序完成2路数据拨号后所建立的APPS与MODEM之间的数据通路情况。如图中所示，在APPS侧创建了2个虚拟网络接口rmnet_data0及rmnet_data1，分别对应了两路数据拨号。这两个接口的数据使用高通的QMAP协议在物理网络接口rmnet_ipa0上复用传输，通过QMAP协议头中的MUX_ID字段来区分。例如，rmnet_data0使用的MUX_ID为1，rmnet_data1使用的MUX_ID为2。MODEM侧从IPA通道上接收到数据后，根据MUX_ID对数据进行分发，将数据传递到对应的通路上。
2.2 物理数据通道及数据传输格式
sdx55平台APSS与MODEM之间的物理数据通道主要是IPA通道。IPA是IP数据硬件加速引擎，完成报文协议头添加及去除，过滤,NAT，IP路由等功能。
APPS进行数据拨号时需要发送设置物理通道数据传输格式的QMI消息QMI_WDA_SET_DATA_FORMAT_REQ_V01，与MODEM协商确立物理通道数据传输格式。数据传输格式的可选配置内容如下表所示。
| 数据传输格式 | 格式说明 |
|---|
| qos_format| Indicates whether the Quality of Service (QOS) data format is used by the client. Values:
- 0 – QOS flow header is not present (Default)
- 1 – QOS flow header is present |
| link_prot| Link protocol used by the client:
- 0x01 – 802.3 Ethernet mode (Default)
- 0x02 – IP mode |
| ul_data_aggregation_protocol| Uplink (UL) data aggregation protocol to be used for uplink data transfer. Values:
- WDA_UL_DATA_AGG_DISABLED (0x00) –
- WDA_UL_DATA_AGG_TLP_ENABLED (0x01) –
- WDA_UL_DATA_AGG_QC_NCM_ENABLED (0x02) –
- WDA_UL_DATA_AGG_MBIM_ENABLED (0x03) –
- WDA_UL_DATA_AGG_RNDIS_ENABLED (0x04) –
- WDS_UL_DATA_AGG_QMAP_ENABLED (0x05) –
- WDA_UL_DATA_AGG_QMAP_ENABLED (0x05) –
- WDS_UL_DATA_AGG_QMAP_V2_ENABLED (0x06) –
- WDA_UL_DATA_AGG_QMAP_V2_ENABLED (0x06) –
- WDA_UL_DATA_AGG_QMAP_V3_ENABLED (0x07) –
- WDA_UL_DATA_AGG_QMAP_V4_ENABLED (0x08) –
- WDA_UL_DATA_AGG_QMAP_V5_ENABLED (0x09) – |
| dl_data_aggregation_protocol| Downlink (DL) data aggregation protocol to be used for downlink data transfer. Values:
- WDA_DL_DATA_AGG_DISABLED (0x00) –
- WDA_DL_DATA_AGG_TLP_ENABLED (0x01) –
- WDA_DL_DATA_AGG_QC_NCM_ENABLED (0x02) –
- WDA_DL_DATA_AGG_MBIM_ENABLED (0x03) –
- WDA_DL_DATA_AGG_RNDIS_ENABLED (0x04) –
- WDS_DL_DATA_AGG_QMAP_ENABLED (0x05) –
- WDA_DL_DATA_AGG_QMAP_ENABLED (0x05) –
- WDS_DL_DATA_AGG_QMAP_V2_ENABLED (0x06) –
- WDA_DL_DATA_AGG_QMAP_V2_ENABLED (0x06) –
- WDA_DL_DATA_AGG_QMAP_V3_ENABLED (0x07) –
- WDA_DL_DATA_AGG_QMAP_V4_ENABLED (0x08) –
-WDA_DL_DATA_AGG_QMAP_V5_ENABLED (0x09) – |
| ndp_signature | NCM Datagram Pointers (NDP) signature |
|---|---|
| dl_data_aggregation_max_size | Maximum size in bytes of a single aggregated packet allowed on downlink.The value applies to all downlink data aggregation protocols when downlink data aggregation is enabled. |
| ep_id | Peripheral end point on which the data format is set.Default value is the default data channel associated with the QMI control channel from which the request is received. |
| qos_header_format| QOS header format to be used on the uplink, on all the protocols,if QOS is enabled. Values:
- WDA_QOS_HDR_FORMAT_RESERVED (0x00) – Reserved
- WDA_QOS_HDR_FORMAT_6_BYTE (0x01) – QOS 6 byte Default header
- WDA_QOS_HDR_FORMAT_8_BYTE (0x02) – QOS 8 byte header |
|dl_minimum_padding|Specifies the minimum padding bytes to be added in between aggregated downlink QMAP packets. Valid values: 0 to 64 bytes; must be 4-byte aligned. Default is 0|
| flow_control| Indicates whether flow control will be done by the TE. Values:
- 0 – Flow control will not be done by the TE (Default)
- 1 – Flow control will be done by the TE |
| ul_data_aggregation_max_datagrams | Maximum number of datagrams in a single aggregated packet allowed on uplink. The value applies only to QMAP uplink data aggregation protocol when it is enabled. Zero means no limit. |
|---|---|
| coalescing_info | Specifies TCP/UDP coalescing setting to be configured on the modem. |
其中，link_prot配置链路协议消息格式，配置消息包是以太网数据包还是IP数据包；ul_data_aggregation_protocol和dl_data_aggregation_protocol配置上下行数据汇聚协议，可配置为MBIM，RNDIS，QMAP等协议格式。
ep_id为Peripheral End Point ID，标识外围设备接入节点，由2个字段组成：节点类型+节点ID，具体如下表：
| 名称 | 解释 |
|---|
| ep_type| Peripheral endpoint type.Values:
-DATA_EP_TYPE_RESERVED (0x00) – Reserved
-DATA_EP_TYPE_HSIC (0x01) – High-speed inter-chip interface
-DATA_EP_TYPE_HSUSB (0x02) – High-speed universal serial bus
-DATA_EP_TYPE_PCIE (0x03) – Peripheral component interconnect express
-DATA_EP_TYPE_EMBEDDED (0x04) – Embedded
-DATA_EP_TYPE_BAM_DMUX (0x05) – BAM demux |
|iface_id|Peripheral interface number|
例如，如果数据从USB接口接入，则ep_type的值设置为DATA_EP_TYPE_HSUSB；从PCIe接口接入，ep_type的值设置为DATA_EP_TYPE_PCIE；如果数据是从APPS到MODEM的，ep_type的值设置为DATA_EP_TYPE_EMBEDDED。
进行数据拨号时需要先发送QMI_DPM_OPEN_PORT_REQ_V01消息通知MODEM打开对应的数据端口(由ep_id标识)。 并且当使用QMAP协议支持多路虚拟接口数据在物理通道上复用传输时，需要发送QMI消息QMI_WDS_BIND_MUX_DATA_PORT_REQ_V01到MODEM进行逻辑端口与物理端口的绑定，这个物理端口也是由ep_id来标识。
总之，ep_id是在MODEM侧可见的。
当使用dsi_netctrl_test程序进行数据拨号时，配置的链路数据格式为IP数据；使用QMAP协议以支持多路虚拟接口在物理接口上复用传输； ep_id对应APSS与MODEM间进行数据传输的IPA通道(rmnet_ipa0)，ep_type的值为DATA_EP_TYPE_EMBEDDED，iface_id为1。
2.3 QMAP协议
QMAP是高通定义的实现数据复用及汇聚的协议，可实现多路虚拟通道数据在单个物理通道上复用传输。具体来说，定义了一个额外的QMAP消息头，消息头中有个字段MUX_ID由于区分不同的虚拟通道。QMAP协议只支持IP数据模式，不支持以太网数据。在物理通道上传输时发送者在IP数据报文前加上QMAP消息头， MUX_ID填充为对应的虚拟通道的ID；接收者根据MUX_ID进行数据分发。
QMAP消息头的格式定义如下图所示。
各字段的定义如下表所示。
| 字段名称 | 字段定义 |
|---|
| C/D bit| 1 bit; indicates if it is a QMAP control command or a data packet
1 – QMAP control command
0 – Data packet |
| R/NEXT_HDR| 老版本的QMAP协议定义为保留字段,值默认为0。
QMAP V5版本用于指示QMAP消息头之后是否还存在其他消息头。
1 – 本消息头之后还存在其他消息头
0 –本消息头之后是IP数据 |
| MUX_ID| 8 bits; indicates mux channel ID
If mux is not negotiated, this field is set to 0 and must be ignored by the receiver；
If mux is negotiated, MUX_ID can be in the range of 1 to 0x7F; MUX_IDs 0 and 0x80 – 0xFF are reserved |
| PAYLOAD_LEN_WITH_PADDING| 16 bits; total payload length in bytes including padding
Does not include QMAP header
Receiver must ignore a packet with this field set to 0; QMAP packet will not carry any payload in this case |
2.4 APPS侧数据流程相关代码分析
2.4.1 虚拟网络接口的创建
- netmgr进程启动时从netmgr_config.xml文件获取物理通道的信息，如名称，数据格式。
如上图所示，phy_net_dev定义了物理网络接口名称为rmnet_ipa0，dataformat_dl_data_aggregation_protocol和dataformat_ul_data_aggregation_protocol配置为9，即QMAP V5；dataformat_agg_dl_pkt为10，dataformat_agg_dl_size为8192说明下行数据支持多个QMAP包汇聚在一个以太网数据包传输；dataformat_agg_ul_pkt和dataformat_agg_ul_size都为0说明上行数据不支持对多个QMAP包进行汇聚处理。
在代码中会根据xml进行配置，也会设置虚拟网卡的枚举个数。
data/netmgr/src/netmgr_config.c
- netmgr启动时调用netmgr_rmnet_configure_embedded_links创建rmnet_data0~ rmnet_data7网络接口，具体流程如下图所示。
函数rmnet_register_real_device注册物理设备，创建了一个struct rmnet_port的实例，并且将物理网络接口(rmnet_ipa0)的接收函数设置为rmnet_rx_handler。
struct rmnet_port存储了物理网络接口相关信息，其中重要的是存储了与该物理网络接口绑定的虚拟网络接口信息，这些虚拟网络接口的数据在物理网络接口上复用传输。
如上图所示，muxed_ep数组存储逻辑网络接口信息，该数组使用MUX_ID作为索引。当调用函数rmnet_newlink创建逻辑网络接口时会创建一个struct rmnet_endpoint实例保存与逻辑网络接口相关的一些信息(如mux_id,指向逻辑网络设备接口的指针)，并将该实例放入链表muxed_ep[MUX_ID]中。其中，MUX_ID为该逻辑网络接口对应的MUX_ID，例如rmnet_data0的MUX_ID为1，rmnet_data1的MUX_ID为1，如此依次类推。
函数rmnet_vnd_newlink调用register_netdevice注册了rmnet_data网络接口，并且对sturct rmnet_endpoint * ep进行初始化。sturct rmnet_endpoint主要在接收数据的时候使用，成员mux_id设置为逻辑网络接口对应的mux id,成员egress_dev被设置为指向逻辑网络接口。当从物理网络接口接收到数据后，从数据的QMAP消息头中提取MUX_ID，根据该MUX_ID找到对应的sturct rmnet_endpoint节点，然后将数据提交给该ep的egress_dev,即对应的逻辑网络接口。
2.4.2 物理网络接口数据接收流程
如前面所述，函数rmnet_register_real_device将物理网络接口(rmnet_ipa0)的数据接收处理函数设置为rmnet_rx_handler。rmnet_rx_handler函数根据QMAP消息头获取MUX_ID，根据MUX_ID找到对应的逻辑网络接口的sturct rmnet_endpoint实例，将IP数据包提交给该逻辑网络接口。主要的处理函数为__rmnet_map_ingress_handler。
如上图所示，rmnet_get_endpoint根据mux_id找到逻辑网络接口对应的sturct rmnet_endpoint实例ep，之后将数据包的设备接口dev修改为ep->egress_dev，即修改为逻辑网络接口对应的设备接口；之后去掉QMAP消息头后调用函数rmnet_deliver_skb_list将IP数据包通过逻辑网络接口提交到上层tcpip协议栈处理。
2.4.3 虚拟网络接口数据发送流程
虚拟网络接口(如rmnet_data0)发送IP数据包时会加上QMAP消息头，MUX_ID填充为该虚拟网络接口对应的MUX_ID；之后将该数据包提交给物理网络接口(rmnet_ipa0),调用物理网络接口的发送函数ipa3_wwan_xmit将消息从物理通道发送给MODEM。
函数rmnet_vnd_start_xmit为虚拟网络接口的数据发送函数，该函数直接调用rmnet_egress_handler对数据包skb进行发送处理。
如上图所示，函数rmnet_egress_handler将数据包skb的设备接口dev修改为物理网络接口对应的设备接口，调用函数rmnet_map_egress_handler添加QMAP消息头，最后调用dev_queue_xmit函数将数据包从物理网络接口发送出去。
函数rmnet_map_egress_handler调用rmnet_map_add_map_header添加QMAP消息头，QMAP消息头中的MUX_ID设置为逻辑网络接口对应的MUX_ID；
3 dsi_netctrl_test数据拨号
dsi_netctrl_test在APPS内部,从APPS发起数据拨号流程，建立APPS与MODEM之间的数据通路。
拨号的过程中需要netmgr应用程序参与，辅助完成APPS内部虚拟网络接口(rmnet_data0)的配置(IP地址、子网掩码等)。本节主要介绍拨号过程中的关键点，详细的拨号过程可以参考实际代码实现。
3.1 dsi_netctrl_test数据拨号流程
拨号过程如下：
获取详细的拨号参数，如IPV4/IPV6的选择，使用哪种通信制式，APN等等。
调用dsi_mni_look_up函数查找本次拨号使用哪个rmnet_data虚拟网络接口。
如上图所示，dsi_netctrl_test发消息到netmgr查找接口信息，netmgr发送NETMGR_QMI_WDS_ROUTE_LOOK_UP_MSG_ID消息到MODEM。MODEM根据拨号参数调用函数rmnet_meta_smi_get_um_iface_ptr查找与之匹配的UM_IFACE，并且如果之前有其他qmi client拨号使用该UM_IFACE，则同时返回该client对应的ep_id和mux_id。
negmgr检查返回结果，如果mux_id有效，说明有其他client使用该UM_IFACE，则直接使用（mux_id-1）作为接口index（即如果mux_id为1，则APPS侧使用rmnet_data0）；否则如果mux_id无效，则调用netmgr_qmi_find_available_iface函数分配一个没有使用过的接口index；
调用函数dsi_mni_init_client(int conn_id)初始化qmi_wds服务的client句柄，为拨号做准备，参数conn_id为步骤2获取的iface_index。
如上图所示，dsi_netctrl_test程序会发送QMI_WDS_BIND_MUX_DATA_PORT_REQ_V01消息到MODEM通知MODEM进行逻辑端口与物理端口的绑定，ep_id标识对应的物理端口，mux_id则对应着逻辑端口。
调用dsi_mni_start函数进行数据拨号
如上图所示，dsi_netctrl_test程序发送QMI_WDS_START_NETWORK_INTERFACE_REQ_V01消息到MODEM通知MODEM进行拨号。
3.2 netmgr配置虚拟网络接口
netmgr监测拨号状态，拨号成功后会获取相关配置(IP地址、网关等)配置虚拟网络接口，具体见下图。
如上图所示，拨号成功后，netmgr应用程序调用netmgr_kif_iface_open函数将对应的虚拟网络接口rmnet_dataX(X=0~7)UP起来；之后调用函数netmgr_kif_iface_configure配置IP地址、子网掩码。