CN102224714A

CN102224714A - 移动无线电通信设备中的客户端服务器通信

Info

Publication number: CN102224714A
Application number: CN200980146605.9A
Authority: CN
Inventors: 奥利维尔·董
Original assignee: NEC Corp
Current assignee: Lenovo Innovations Co ltd Hong Kong
Priority date: 2008-11-20
Filing date: 2009-07-31
Publication date: 2011-10-19
Anticipated expiration: 2029-07-31
Also published as: US20110228738A1; CN102224714B; JP2012509606A; EP2353258A1; WO2010058634A1; EP2353258B1; US8948101B2; JP5447522B2; GB0821236D0; EP2353258A4

Abstract

本发明提供了一种用于移动无线电通信设备中服务器模式中的芯片卡和每个都具有相同IP地址的多个客户端中的任意一个或多个客户端之间的通信的方法，该方法包括以下步骤：为客户端中的每个创建一个套接字，其中每个套接字要被绑定到由该设备分配的一个客户端端口，将客户端标识符与每个绑定的客户端端口相关联，以及使得每个所述客户端标识符对该芯片卡可用，从而该芯片卡可以区分来自这多个客户端的消息。

Description

移动无线电通信设备中的客户端服务器通信

技术领域

本发明涉及用于移动无线电通信设备内的通信的方法，并且涉及相关无线电通信设备和其中产生的信令。

背景技术

诸如蜂窝电话手机之类的移动无线电通信设备早已采用芯片卡(chip-card)，例如订户身份模块(SIM)，3G手机的通用集成电路卡(UICC)。这种卡通常被布置为包含有主叫方和网络相关信息，并且包括存储器和微控制器功能。

这种在移动无线电通信设备中采用的已知的芯片卡越来越复杂，并且其他功能还包括在芯片卡内设置服务器使得例如UICC可以工作在服务器模式中，该服务器模式针对位于移动无线电通信设备移动装备(ME)本地或者远程的一个或多个客户端。

尽管可以容易地向这种芯片卡提供这种与客户端通信的服务器功能，但是存在这样的场景：其中要求服务器与每个都具有相同IP地址的多个客户端中的一个或多个客户端通信，例如在与该芯片卡服务器相同的ME上设置的多个本地客户端。

芯片卡服务器和ME之间的通信一般是由载体无关协议(BIP)支持的。然而，通过BIP通道递送的信息负载不包括用来指示信令源自的客户端的信息，因此服务器芯片卡通过固有方式不能区分源自各个都共享同一IP地址的不同客户端的负载。

已知例如服务器模式中的UICC支持基于BIP信道的传输控制协议(TCP)，并且其中存在共享同一IP地址的多个客户端。这里为每个具体的TCP连接提供一个特定的BIP信道。然而，提供多个独立BIP信道的缺点是对于ME和例如芯片卡二者都相对比较消耗资源，并且需要额外的配置以保持来自不同客户端的数据独立，并且一般要求提供若干个缓冲器。

另外，与支持基于BIP信道的TCP相关联的开销可以证明不利地限制了服务器芯片卡ME接口工作的相对安全和可靠的环境。

本发明试图提供一种方法，用于在移动无线电通信设备中服务器模式中的芯片卡和每个都具有相同IP地址的多个客户端中的任意一个之间通信，并且该方法优于已知的这种方法。同样，本发明试图提供相关移动无线电通信设备以及其中产生的信令，该设备和信令优于已知的这种设备和相关信令。

发明内容

根据本发明的一个示例方面，提供了一种用于移动无线电通信设备中服务器模式中的芯片卡和每个都具有相同IP地址的多个客户端中的任意一个或多个客户端之间的通信的方法，该方法包括以下步骤：为客户端中的每个创建一个套接字(socket)，其中每个套接字被绑定到由该设备分配的一个客户端端口，将客户端标识符与每个绑定的客户端端口相关联，以及使得每个所述客户端标识符对该芯片卡可用，从而该芯片卡可以区分来自这多个客户端的消息。

因此，将理解本发明有利地允许诸如UICC之类的芯片卡基于在移动无线电通信设备中控制的套接字-端口配对来区分多个客户端。

另外，该方法可提供来用于包括服务器模式中的UICC在内的芯片卡和多个客户端之间的通信。

此外，该方法可提供来用于在移动无线电通信这边中设置的芯片卡和多个客户端之间的通信。

当然，应当理解该通信方法可被布置为由移动无线电通信系统中的BIP信道支持。

有利地，在本发明的方法中，要被绑定到一具体客户端套接字的客户端端口可通过该移动无线电通信设备分配。

或者，要被绑定到一具体客户端套接字的客户端端口可从预定端口选择导出。

此外，可将该方法布置为使得移动无线电通信设备存储客户端端口和配对的客户端标识符信息。

有利地，该方法可以包括使得客户端标识符对移动无线电通信设备-芯片卡接口可用的步骤。

优选地，该方法可以包括对服务器和(多个)客户端之间的通用数据报协议通信的支持。

这样，对UDP服务器模式中的芯片卡的支持可在APDU命令信令中提供。

此外，对UDP服务器模式中的芯片卡的支持可在开放信道前摄命令信令中提供。

作为替换，该方法还可以包括支持TCP通信并且按需创建TCP套接字。

这样，该方法还可以包括监控服务器端口上的进入连接请求的步骤。

该方法还可以包括创建其他TCP服务器套接字，并且响应于进入连接请求留下原服务器套接字用于将来进入的连接请求。

根据本发明另一个示例方面，提供了一种移动无线电通信设备，该移动无线电通信设备具有芯片卡，并且布置来根据如上限定的用于通信的方法操作。这种如上所述的移动无线电通信设备可布置来执行用于控制该方法的软件指令。

根据本发明又一个示例性方面，提供了一种到移动无线电通信设备内的服务器模式中的芯片卡的信令消息，所述消息源自每个都具有相同IP地址的多个客户端中的一个客户端，并且所述消息包括与绑定的套接字和客户端端口相关联的客户端标识符，使得所述芯片卡能区分来自这多个客户端的消息。

优选地，该信令包括终端响应消息。

根据本发明又一个示例性方面，提供了一种来自移动无线电通信设备内的服务器模式中的芯片卡的信令消息，该信令消息要被递送到每个都具有相同IP地址的多个客户端中的至少一个客户端，并且所述信令消息包括与绑定的套接字和客户端端口相关联的客户端标识符，使得所述芯片卡能针对该信令消息的递送区分所述多个客户端。

有利地，该信令包括发送数据命令消息。

将理解，通过移动无线电通信设备中的功能，例如通过该移动无线电通信设备中的套接字层，或者通过分配给特定类型应用的预定端口号，可以向这多个客户端中的每个分配一个端口号。

此外，本申请因此有利地提供了允许芯片卡基于移动无线电通信设备中的功能区分多个客户端，并且有利地考虑了与现有卡接口相关的约束，以辅助实现本发明的向后兼容。

具体而言，本发明基于例如如下多个过程步骤的组合：识别端口号，与可减少移动无线电通信设备-芯片卡接口上所要求的比特/字节的简单标识符相关联，并且扩展接口上的现有参数的范围，从而向芯片卡而不是仅移动无线电通信设备提供所要求的能力来区分每个都具有相同IP地址的多个客户端。

从而例如尽管在当前在文档ETSI TS 102 223中定义的基于BMP信道的UICC服务器模式仅支持TCP模式通信，但是本发明提供了一种尤其有利的机制用于支持这种通信，并且还支持UDP模式操作，使得例如该移动无线电通信设备中的任何应用基于UDP可以随后与类似地布置在UDP服务器模式中工作的芯片卡交互。

因此在移动无线电通信设备和芯片卡服务器接口的上下文中，从而在任何情形中都可能不需要TCP模式的额外安全性和可靠性的场景中，可以容易地得到使用UDP模式而带来的速度和效率方面的优点。

下面参考附图仅作为示例来进一步描述本发明。

附图说明

图1是下述场景的协议栈和处理流程的示意性框图：在该场景中，在移动无线电通信设备和芯片卡二者中都支持UDP；

图2是与图1的类似的栈和处理流程图，只是在该场景中在接口的芯片卡一侧仅支持BIP；

图3是根据本发明一个实施例在移动无线电通信设备中芯片卡和多个客户端之间的信令图；

图4根据另一个实施例在移动无线电通信设备中芯片卡和多个客户端之间的类似但仅是一部分的信令图；以及

图5图示了终端简档消息中的修改后的结构，使得支持UDP服务器模式中的芯片卡。

具体实施方式

参考文章ETSI TS 102 223 Rel-8 Specs，已知服务器模式中的UICC支持基于BIP信道的TCP，并且使得仅移动无线电通信设备移动装备(ME)中的TCP客户端应用和UICC中的TCP服务器可以通过BIP信道通信。

然而，每个都具有相同IP地址的多个客户端和服务器模式中的UICC可以通信的方式被不利地限制，并且仅支持TCP模式可以类似地证明是不合适并且受限的。

从上面将理解，本发明提供了一种机制，通过该机制，例如服务器模式中的UICC可以可靠地与每个都具有相同IP地址的多个客户端中的一个或多个客户端通信，并且还提供了另一种机制，该机制允许支持基于BIP信道的UDP，使得每个客户端可以包括UDP客户端，并且服务器模式中的UICC可以包括UICC UDP服务器。

下面进一步描述根据本发明两个具体实施例产生的信令，首先参考图1，图1示出了在ME和接口的UICC侧上都支持UDP/IP的场景的协议栈和处理流程，但是应理解图1仅示出了客户端侧上的处理。即，示出了客户端(应用)10、随后设置的提供可以包括源、目的地和端口号的头部的UDP栈12、随后设置的BIP之前的IP支持14、或者以太网仿真16、随后前进到物理层18，其可以包括通用串行总线(USB)连接或其他连接。

然后，现在转到图2，示出了在UICC侧仅支持BIP，从而使得不设置UDP/IP或者实际上TCP栈的场景。

如图所示，在接口的客户端侧20处，设置了客户端(应用)24和相关UDP发送请求26。由于ME可以识别出在UICC侧仅支持BIP，所以UDP层26将仅将UDP发送请求转发到BIP层28。在这里，BIP层28从该UDP发送请求提取客户端(应用)24数据，并将客户端端口与后面将描述的标识符相关联。

然后该数据准备好经由接口被发送到UICC侧。

在该接口的UICC侧22处，物理层包括例如USB 34并且接收数据，该数据随后经由BIP 36被递送到UICC内的服务器38。

如上所述，与两个独立实施例相关产生的信令的具体示例将结合本申请的图3和4进一步讨论。

为了实现在UICC内尤其高效地识别源自多个客户端中的一个或多个的数据，本发明特别支持基于BIP信道的UDP。

然而，应当理解，本发明绝不限于支持UDP。例如，UICC可以确定进入数据的客户端源并且可以将数据再递送到适当的目标客户端的有利方式不限于任何具体的通信方式，例如UDP或TCP。

然而，仅为了进一步说明，对于支持UDP，应当理解，本发明可以在终端简档(terminal profile)APDU命令中支持UICC UDP服务器模式，并且还可以在开放信道前摄(proactive)命令中支持UICC UDP服务器模式。

根据需要，多个UDP客户端应用中的任意一个或多个被布置来创建UDP套接字，并且重要地是将该套接字绑定到一个具体的端口号。该端口号可由ME分配，或者可以从预先设定的预定范围提取，并且随后可被定义或者识别为该具体客户端应用的源(或客户端)端口号。

随后可将ME布置来将下文称作“UDP客户端标识符”的标识符关联到前述客户端源端口号中的每一个。

这种源端口号和UDP客户端标识符对可以仍适当地存储在ME中。

为了允许在UICC中实现本发明的期望区分功能，可使UDP客户端标识符对ME-UICC接口可用，并且这例如可以通过信封事件下载数据(Envelope Event Download Data)、接收数据、发送数据和/或终端响应命令来实现。

UICC随后可以基于该UDP客户端标识符区分多个UDP客户端。

现在转到图3，给出了在ME中，在UDP服务器模式中第一和第二客户端40、42、主ME处理器44和UICC 46之间产生的信令的图。

在加电序列(power-up sequence)中，ME 44将其终端简档消息48发送到UICC 46，指示该ME 44支持“UICC UDP服务器模式”。

一旦加电序列完成，UICC 46就向ME 44发送一开放信道前摄命令50指示其希望打开一UICC UDP服务器模式中的信道(尽管这可以在发送了终端简档后的任意时刻发生)。具体而言，命令50包括相关服务器端口号，即，UDP服务器46用来与UDP客户端应用通信的端口。

ME 44接受该命令，具体而言，记忆前述UDP服务器端口号。对于该信令过程中的后续步骤，ME 44将监控(52)是否在该特定服务器端口上接收到任何数据。

假设ME 44中的第一UDP客户端40应用希望与UDP模式中的UICC服务器46通信，则该应用将首先创建(54)一个UDP套接字，然后将该套接字与源端口号绑定(54)，该源端口号可称作客户端源端口号。注意，该端口号可以预先固定，或者例如如果ME 44已动态分配了端口号则可以通过调用原语“getsockname”而提取。

随后，ME 44记忆该客户端端口号，并将一UDP客户端标识符(例如，由ME分配的一个简单数字)关联(56)到该端口号。

这可以通过在ME中利用一个简单阵列来存储“客户端端口号-UDP客户端标识符”对数据来实现。

将看到，随后对第二UDP客户端应用42进行类似的信令58、60和标识符分配62。在第一UDP客户端应用40调用UDP发送数据函数来向UICC UDP服务器46发送数据64时，注意UDP客户端预先知道该UICCUDP服务器端口号，并且该端口可以是由IANA分配的标准端口号。

ME 44根据在发送函数64中由UDP客户端40指示出的服务器端口号将该请求识别为对UICC UDP服务器46的请求，ME 44然后将从该函数提取负载并且将其保存到其存储器中。

ME 44随后向UICC UDP服务器46发送“事件下载数据可用”信封命令66，指示例如所分配的UDP客户端标识符在该信封命令66中包括的设备身份数据对象中。

通过接收信封66，UICC 46基于该UDP客户端标识符确认存在UDP客户端，其识别为试图与UICC UDP服务器通信。

UICC 46随后向ME 44发送接收数据命令68，以便提取来自UDP客户端40的数据。具体而言，接收数据命令68也可以包含UDP客户端标识符。

通过接收该接收数据命令68，ME 44可以将由该UDP客户端标识符所引用(所指)的UDP客户端应用数据(先前保存的负载)封装到“信道数据”数据对象中，包括UDP客户端标识符(例如，在设备身份数据对象中)，然后向UICC 46发送终端响应70。

应当理解，如果不能利用单个终端响应发送UDP客户端数据，即，在数据量超出了单个终端响应的数据传输能力的情况下，可以采用服务器的“接收数据-终端响应”交换/循环。

通过接收该终端响应70，UICC 46将能够根据UDP客户端标识符了解数据源自哪个UDP客户端(在该情形中是40)。

ME 44随后可以通过向UDP客户端发送确认消息72来确认正确发送了数据。

在第二客户端应用42UDP调用UDP发送函数来向UICC UDP服务器46发送数据74时将发生类似的信令交换74、76、78、80和82。

接着，UICC服务器46可以向特定UDP客户端40、42发送数据84、86，并且根据本发明，UICC随后将仅需在发送数据前摄命令84中指定UDP客户端标识符。

当ME 44从UICC 46接收到该发送数据命令84时，根据“UDP客户端标识符/客户端端口号”对信息，ME 44将能够将该数据86发送到正确的客户端应用40。

现在转到图4，示出了在第一和第二客户端40、42、ME主处理器44和UICC46之间发生的信令，只是这次是根据支持基于BIP信道的TCP。即，客户端40、42每个都包括TCP客户端，并且考虑UICC 46工作在TCP服务器模式中。

从下面的描述将理解，图4中仅示出了信令的最初阶段，因为随后的交换仅仅是结合图3的实施例描述的那些的镜像。

同样，以加电序列开始，ME 44向UICC 46发送终端简档信号88，信号88指示支持服务器模式中的UICC和TCP，并且和前面一样，完成加电序列后，UICC 46向ME 40发送开放信道前摄命令90。

在该阶段中，如92所示，ME随后创建一TCP套接字，并将该套接字与所需的服务器端口绑定。还可以启动相关“监听”和随后的“接受”功能，使得ME可以开始监控该服务器端口上的任何进入连接请求。

对于后续对来自第一客户端40的通信的支持，信令94、96被从该客户端40递送到ME 44，以便创建所需的TCP套接字，并且随后将该套接字绑定到适当的客户端端口号。

在ME 44中(98)，该ME接收前述连接请求，并且有效地创建一个新的TCP服务器套接字，以便留下原服务器套接字可用于任意将来进入的连接请求。可以将ME布置为分配新的服务器端口号，并且从此向前，该新分配的端口号被与第一客户端40相关联，并且来自该客户端的所有将来数据都将被发送到该具体端口。

随后，ME 44可以通过信令100来以对该连接请求的接收和使能的确认作出响应。

接下来，假设第二客户端42类似地希望与UICC 46通信，则在ME44处从该第二客户端接收到类似的套接字创建102和绑定104信令。从而在106处，结合第二客户端执行结合第一客户端在98处进行的相同的端口号分配处理。

然后对该连接的接收和使能的确认作为信令108被从ME 44返回到第二客户端42。所有后续信令在与图3所示的对UDP的支持相同的上下文中发生，因此未进一步示出。在确认中，ME已向第一和第二客户端40、42分配了两个不同的端口号。ME随后可以将端口号与两个不同的标识符相关联，并传递该信息以由UICC使用从而允许该UICC区分源自两个不同客户端的数据，即使它们共享同一个IP地址。

返回到支持UDP的实施例，这可以基于为支持TCP而提议的信令，只是如下面的提议所述包括一些添加和修改。

例如，可以将“终端简档”APDU命令修改为添加对“UDP服务器模式中的UICC”的支持。

图5中参考第17字节示出了对APDU命令的这种建议修改的本质，示出了在“b6”处添加了对服务器模式中的UDP UICC的支持。

另外，还可以修改“与UICC服务器模式有关的开放信道”前摄命令，以便添加对UDP服务器模式中的UICC的支持。

更具体而言，可以修改在该开放信道命令中包括的“UICC/终端接口传输级别”数据对象，以便添加对UDP服务器模式中的UICC的支持。

在该UICC/终端接口传输级别，如果支持类别“e”，则该语句应用。

字节	描述	长度
			1	UICC/终端接口传输级别标签	1
2	长度＝“03”	1
			3	传输协议类型	1
4-5	端口号	2

●传输协议类型的编码

-‘01’：UDP、客户端模式中的UICC、远程连接；

-‘02’：TCP、客户端模式中的UICC、远程连接；

-‘03’：TCP、服务器模式中的UICC；

-‘04’：UDP、客户端模式中的UICC、本地连接；

-‘05’：TCP、客户端模式中的UICC、本地连接；

-‘06’：UDP、服务器模式中的UICC；

-所有其他值保留

-UDP在RFC 768[9]中定义；TCP在RFC 793[10]中定义

●端口号的编码

-整数。

应当理解，值“06”被提供来作为示例，因为这基于一个具体版本的规范，当然如果需要的话该值可以被改变。

对于“设备身份”数据对象，可以对其进行修改以便添加允许区分多个UDP客户端的标识符。另外，可以定义新的值范围。例如，在本发明的一个实施例中，可以定义9个可能的值(31-39)。当然，应当理解，这不是限制，并且可以利用诸如41-49等的其他值进一步扩展。

现在参考设备身份(设备标识)，这些可以如下布置。

字节	描述	长度
			1	设备身份标签	1
2	长度＝“02”	1
			3	源设备身份	1
4-5	目的地设备身份	2

源设备身份：

●内容：

-保存在随后的数据对象中的信息的源设备。

目的地设备身份：

●内容：

-保存在随后的数据对象中的信息的目的地设备。

通常，应当注意仅允许命令类型、数据下载类型和设备身份的一些组合。这些在语句10中定义。

●编码

-源和目的地设备身份都被如下编码：

■‘01’＝键盘；

■‘02’＝显示器；

■‘03’＝听筒；

■‘10’-‘17’＝附加读卡器x(0-7)。值由终端指定；

■‘21’-‘27’＝信道标识符为x(1-7)的信道。值由终端在开放信道命令后的终端响应的信道状态内涵TLV中指定；

■‘31’-‘39’＝在支持UDP服务器模式中的UICC的情形中，UDP客户端应用标识符(1-9)；

■‘81’＝UICC；

■‘82’＝终端；

■‘83’＝网络；

■所有其他值保留

同样，注意该设备身份数据对象可被包括在以下命令中。

-从ME到UICC

*信封“事件下载-数据可用”

*终端响应

-从UICC到ME

*接收数据

*发送数据

将理解，ME必需将UDP客户端应用源端口(参见下面)与上面的UDP客户端应用标识符相关联。

在ME 44中的UDP客户端应用40、42和UICC 46中的UDP服务器之间的任何通信之前，客户端应用40、42首先被与端口号相关联，以便能够从服务器46提取任何数据(应答)，并且注意该过程可以如下：

-客户端首先创建UDP数据报套接字，这可以利用任意标准套接字库完成：

hSocket＝socket(AF_INET，SOCK_DGRAM，IPPROTO_UDP)；

-根据本发明的该示例，客户端随后将该套接字绑定到具体端口号(这将是客户端源端口号)，并且该端口号可以被预先固定，或者由ME如下动态分配：

bind(hSocket，(struct sockaddr*)&address，size of(address))。

应当注意，客户端IP地址和端口号都包含在“sockaddr”结构中，从此点来说，ME必需将UDP客户端标识符与该客户端端口号相关联。这可以通过可存储在ME存储器中的如下格式中的简单阵列实现。

UDP客户端端口号	UDP客户端标识符
		2222	31
2257	32
		2378	33
2453	34

在ME-UICC接口上，随后将使用UDP客户端标识符来区分多个UDP客户端。

例如，利用上述值，当ME 44中的UDP客户端应用40、42利用端口2222向UICC 46中的服务器发送数据时，ME 44将把标识符“31”与数据一起传递给UICC 46。

在UICC 46发送回复时，其将在其应答中指示“31”。ME 44随后将把该数据发送到UDP端口2222。

通过将客户端应用UDP套接字绑定到相同的本地UDP端口，ME可以简单清楚地识别这些UDP客户端应用中的每一个。UICC UDP服务器对来自ME的多个UDP客户端的支持随后将以简单的方式实现，因为仅需要单个标识符以便允许UICC区分多个UDP客户端。

本发明的这种示例性实施例也具有如下示例性优点：保持现有接口几乎不变，因为可以在现有数据对象中传递新的UDP客户端标识符，并且不会导致任何向后兼容问题。

尽管已结合本发明的示例性实施例具体示出并描述了本发明，但是本发明不限于这些示例实施例。本领域技术人员将理解，在不脱离权利要求所限定的本发明的精神和范围的情况下，可以在形式和细节上作出各种改变。

本申请基于2008年11月20日提交的英国专利申请No.0821236.7并要求该申请的优先权，该申请的公开通过引用整体结合于此。

Claims

1.一种用于移动无线电通信设备中服务器模式中的芯片卡和每个都具有相同IP地址的多个客户端中的任意一个或多个客户端之间的通信的方法，

所述方法包括：

为所述客户端中的每个创建一个套接字，其中每个套接字被绑定到一个客户端端口；

将客户端标识符与每个绑定的客户端端口相关联；以及

使得每个所述客户端标识符对所述芯片卡可用，从而所述芯片卡可以区分所述多个客户端。

2.如权利要求1所述的方法，其中所述芯片卡包括服务器模式中的UICC。

3.如权利要求1或2所述的方法，其中所述多个客户端设置在所述移动无线电通信设备中。

4.如权利要求1至3中任一个所述的方法，其中分配来绑定到一具体套接字的所述客户端端口是通过所述移动无线电通信设备分配的。

5.如权利要求1至3中任一个所述的方法，其中要绑定到一具体套接字的所述客户端端口是从预定端口选择导出的。

6.如权利要求1至5中任一个所述的方法，包括使得所述客户端标识符对移动无线电通信设备-芯片卡接口可用。

7.如权利要求1至6中任一个所述的方法，被布置来支持服务器和多个客户端之间的通用数据报协议通信。

8.如权利要求7所述的方法，其中对芯片卡和UDP服务器模式的支持是在APDU命令信令中提供的。

9.如权利要求7或8所述的方法，其中对芯片卡和UDP服务器模式的支持是在开放信道前摄命令信令中提供的。

10.如权利要求1至6中的任一个所述的方法，被布置来支持TCP通信并且按需创建TCP套接字。

11.一种到移动无线电通信设备内的服务器模式中的芯片卡的信令消息，所述消息源自每个都具有相同IP地址的多个客户端中的一个客户端，并且所述消息包括与绑定的套接字和客户端端口相关联的客户端标识符，使得所述芯片卡能区分所述多个客户端。

12.如权利要求11所述的消息，包括终端响应消息。

13.如权利要求11所述的消息，包括数据可用消息。

14.一种来自移动无线电通信设备内的服务器模式中的芯片卡的信令消息，该信令消息要被递送到每个都具有相同IP地址的多个客户端中的至少一个客户端，并且所述信令消息包括与绑定的套接字和客户端端口相关联的客户端标识符，使得所述芯片卡能区分所述多个客户端。

15.如权利要求14所述的消息，包括发送数据命令消息。

16.如权利要求14所述的消息，包括接收数据命令消息。