本發(fā)明涉及計(jì)算機(jī)網(wǎng)絡(luò)領(lǐng)域，特別是涉及一種網(wǎng)絡(luò)協(xié)議(Internet Protocol，簡稱為IP)地址分配方法及裝置。

背景技術(shù)：

在固網(wǎng)及移動(dòng)網(wǎng)用戶接入過程中，均涉及到用戶IP地址分配的問題。目前通過在網(wǎng)絡(luò)接入服務(wù)器(Network Access Server，簡稱為NAS)側(cè)配置地址池的方式實(shí)現(xiàn)IP地址的分配。圖1是現(xiàn)有技術(shù)中多NAS分配地址的應(yīng)用場景的示意圖，如圖1所示，一個(gè)網(wǎng)絡(luò)中包括多個(gè)NAS，每個(gè)NAS配置的地址池相互獨(dú)立，不能有重疊。圖1中的四個(gè)NAS，上面兩個(gè)其地址段已耗盡，下面兩個(gè)則很多空閑。另一時(shí)間段可能又是相反的結(jié)果，即上面兩個(gè)空閑，下面兩個(gè)耗盡。因此，這樣的部署方式容易造成資源的不均衡，例如，在每個(gè)NAS劃分的地址池過小時(shí)，則高峰時(shí)段不夠用，而過大則浪費(fèi)。因而每一個(gè)NAS都要預(yù)留相當(dāng)一部分地址容量。此外，現(xiàn)有技術(shù)中還存在一個(gè)NAS地址池資源緊張，另一個(gè)NAS地址池很空閑的情況。因此目前急需解決IP地址池分配的問題。

技術(shù)實(shí)現(xiàn)要素：

鑒于現(xiàn)有技術(shù)中預(yù)先分配獨(dú)立地址池時(shí)造成資源分布不均及浪費(fèi)的問題，提出了本發(fā)明以便提供一種克服上述問題的IP地址分配方法及裝置。

本發(fā)明提供一種網(wǎng)絡(luò)協(xié)議IP地址分配方法，包括：預(yù)先將網(wǎng)絡(luò)接入服務(wù)器NAS原有的地址池劃分為多個(gè)小粒度的地址段，并將劃分后的地址段信息保存到地址段狀態(tài)服務(wù)器；在進(jìn)行IP地址申請(qǐng)時(shí)，如果本地不存在已經(jīng)申請(qǐng) 的地址段，或者本地存在已申請(qǐng)的地址段但該地址段中沒有空閑IP地址，NAS則向地址段狀態(tài)服務(wù)器申請(qǐng)一個(gè)新地址段，從新地址段中為NAS進(jìn)行IP地址分配。

本發(fā)明還提供了一種網(wǎng)絡(luò)協(xié)議IP地址分配裝置，具體包括：劃分模塊，用于預(yù)先將其原有的地址池劃分為多個(gè)小粒度的地址段，并將劃分后的地址段信息保存到地址段狀態(tài)服務(wù)器；分配模塊，用于在進(jìn)行IP地址申請(qǐng)時(shí)，如果本地不存在已經(jīng)申請(qǐng)的地址段，或者本地存在已申請(qǐng)的地址段但該地址段中沒有空閑IP地址，則向地址段狀態(tài)服務(wù)器申請(qǐng)一個(gè)新地址段，從新地址段中為NAS進(jìn)行IP地址分配。

本發(fā)明有益效果如下：

通過將原有的地址池劃分為多個(gè)小粒度的地址段，并由地址段狀態(tài)服務(wù)器控制地址段的使用狀態(tài)，在IP地址分配時(shí)，發(fā)送請(qǐng)求消息到地址段狀態(tài)服務(wù)器進(jìn)行地址段申請(qǐng)，解決了現(xiàn)有技術(shù)中預(yù)先分配獨(dú)立地址池時(shí)造成資源分布不均及浪費(fèi)的問題，既可仍由NAS動(dòng)態(tài)分配IP，又可多NAS共享整個(gè)IP地址池。在兼容原網(wǎng)絡(luò)的同時(shí)又避免了集中式分配IP時(shí)性能降低及中斷影響，提高了IP地址資源的利用率。

上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實(shí)施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點(diǎn)能夠更明顯易懂，以下特舉本發(fā)明的具體實(shí)施方式。

附圖說明

通過閱讀下文優(yōu)選實(shí)施方式的詳細(xì)描述，各種其他的優(yōu)點(diǎn)和益處對(duì)于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實(shí)施方式的目的，而并不認(rèn)為是對(duì)本發(fā)明的限制。而且在整個(gè)附圖中，用相同的參考符號(hào)表示相同的部件。在附圖中：

圖1是現(xiàn)有技術(shù)中多NAS分配地址的應(yīng)用場景的示意圖；

圖2是本發(fā)明實(shí)施例的IP地址分配方法的流程圖；

圖3是本發(fā)明實(shí)施例的IP地址段部署示意圖；

圖4是本發(fā)明實(shí)施例的IP地址段請(qǐng)求及響應(yīng)的信令流程圖；

圖5是本發(fā)明實(shí)施例的RFC2882定義的消息類型的示意圖；

圖6是本發(fā)明實(shí)施例的Framed-Route屬性定義的示意圖；

圖7是本發(fā)明實(shí)施例的通過Resource-Query-Request/Reponse消息進(jìn)行地址段申請(qǐng)的信令流程圖；

圖8是本發(fā)明實(shí)施例的IP地址分配裝置的結(jié)構(gòu)示意圖。

具體實(shí)施方式

下面將參照附圖更詳細(xì)地描述本公開的示例性實(shí)施例。雖然附圖中顯示了本公開的示例性實(shí)施例，然而應(yīng)當(dāng)理解，可以以各種形式實(shí)現(xiàn)本公開而不應(yīng)被這里闡述的實(shí)施例所限制。相反，提供這些實(shí)施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。

為了解決現(xiàn)有技術(shù)中預(yù)先分配獨(dú)立地址池時(shí)造成資源分布不均及浪費(fèi)的問題，本發(fā)明提供了一種IP地址分配方法及裝置，主要涉及到的網(wǎng)元包括網(wǎng)絡(luò)接入服務(wù)器(Network Access Server，簡稱為NAS)及地址段狀態(tài)服務(wù)器，本發(fā)明實(shí)施例的技術(shù)方案是點(diǎn)對(duì)點(diǎn)協(xié)議(Point to Point Protocol，簡稱為PPP)/IP控制協(xié)議(IP Control Protocol，簡稱為IPCP)等協(xié)議流程的有益補(bǔ)充。具體地，將負(fù)責(zé)管理的所有地址劃分為多個(gè)小段，由一個(gè)地址段狀態(tài)服務(wù)器維護(hù)其分配狀態(tài)；NAS服務(wù)器需要分配地址時(shí)檢查本地已申請(qǐng)到的地址段中是否包含空閑IP，存在時(shí)則直接分配；不存在時(shí)則向服務(wù)器通過發(fā)送請(qǐng)求消息進(jìn)行申請(qǐng)新的地址段；NAS及地址段狀態(tài)服務(wù)器均可通過發(fā)送釋放消息進(jìn)行IP地址段的釋放。本發(fā)明實(shí)施例的技術(shù)方案對(duì)于解決多NAS分別固定地址池預(yù)先分配方式帶來的IP分配不均及資源浪費(fèi)有很好的效果。以下結(jié)合附圖以及實(shí)施例，對(duì)本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅僅 用以解釋本發(fā)明，并不限定本發(fā)明。

方法實(shí)施例

根據(jù)本發(fā)明的實(shí)施例，提供了一種IP地址分配方法，圖2是本發(fā)明實(shí)施例的IP地址分配方法的流程圖，如圖2所示，根據(jù)本發(fā)明實(shí)施例的IP地址分配方法包括如下處理：

步驟201，預(yù)先將NAS原有的地址池劃分為多個(gè)小粒度的地址段，并將劃分后的地址段信息保存到地址段狀態(tài)服務(wù)器；需要說明的是，NAS包括但不限于PDSN/GGSN/PDN-GW。也就是說，在步驟201中，如圖3所示，需要將各NAS原有的大地址池劃分為多個(gè)小粒度的地址段，并將使用權(quán)限的分配移至地址段狀態(tài)服務(wù)器。例如，圖3中的NAS1包括三個(gè)地址段，各個(gè)地址段的狀態(tài)是其中一個(gè)地址段無空閑，另兩個(gè)地址段有空閑。

步驟202，網(wǎng)絡(luò)接入服務(wù)器在進(jìn)行IP地址申請(qǐng)時(shí)，如果本地不存在已經(jīng)申請(qǐng)的地址段，或者本地存在已申請(qǐng)的地址段但該地址段中沒有空閑IP地址，則向地址段狀態(tài)服務(wù)器申請(qǐng)一個(gè)新地址段，從新地址段中為NAS進(jìn)行IP地址分配。

上述步驟201和步驟202可以由NAS執(zhí)行相關(guān)操作。

在本發(fā)明實(shí)施例中，如果本地存在已申請(qǐng)的地址段并該地址段中含有空閑IP地址，則NAS直接從該地址段中為NAS進(jìn)行IP地址分配。

也就是說，在本發(fā)明實(shí)施例中，在NAS有分配地址池的需求時(shí)，先查看本地是否有已申請(qǐng)的地址段且含空閑IP，有則按原有動(dòng)態(tài)分配IP的流程從該地址段中分配一個(gè)地址。如果沒有則如圖4所示，發(fā)送申請(qǐng)地址段的消息(IP地址段請(qǐng)求)到地址段狀態(tài)服務(wù)器，通過IP地址段響應(yīng)消息獲取到新的地址段后，從中分配新地址。

此外，在用戶釋放IP地址后，如果整個(gè)地址段中所有的IP地址均空閑，則NAS釋放該地址段并通知地址段狀態(tài)服務(wù)器。并且，在接收到地址段狀態(tài)服務(wù)器發(fā)送的釋放地址段請(qǐng)求后，NAS釋放相應(yīng)的用戶會(huì)話及IP地址。也就 是說，NAS在用戶下線釋放地址之后，如果出現(xiàn)整個(gè)小地址段空閑，則可以發(fā)送該地址段的釋放流程。地址狀態(tài)服務(wù)器因管理需要，也可以主動(dòng)發(fā)送釋放指定地址段的請(qǐng)求，NAS在收到之后需要釋放相應(yīng)用戶會(huì)話及IP。

NAS周期性向地址段狀態(tài)服務(wù)器發(fā)送地址段使用情況心跳消息；地址段狀態(tài)服務(wù)器在預(yù)定時(shí)間段內(nèi)沒有收到地址段使用情況心跳消息，則將相應(yīng)的地址段設(shè)置為空閑可分配狀態(tài)。也就是說，NAS需要周期性發(fā)送地址段的使用情況的心跳消息，以保證地址段的時(shí)效性。地址段狀態(tài)服務(wù)器收到心跳消息后更新地址段的時(shí)間；如果長時(shí)間未收到心跳消息則釋放該地址段，置為空閑可分配狀態(tài)。

需要說明的是，IP地址申請(qǐng)消息定義及地址段狀態(tài)服務(wù)器均可根據(jù)網(wǎng)絡(luò)環(huán)境及部署情況靈活實(shí)現(xiàn)。不限于TCP/UDP，也不限于是標(biāo)準(zhǔn)協(xié)議還是自定義消息格式。

以下結(jié)合附圖，對(duì)本發(fā)明實(shí)施例的上述技術(shù)方案進(jìn)行詳細(xì)說明。

在本發(fā)明實(shí)施例進(jìn)行實(shí)施時(shí)，基于現(xiàn)有網(wǎng)絡(luò)中普遍使用的Radius協(xié)議，并利用RFC2882定義的消息類型是一種代價(jià)最小的實(shí)施方案。圖5是本發(fā)明實(shí)施例的RFC2882定義的消息類型的示意圖，此外，本發(fā)明實(shí)施例同時(shí)采用將AAA作為地址段狀態(tài)服務(wù)器，可以減少對(duì)現(xiàn)網(wǎng)的改動(dòng)。

步驟1，Resource-Query-Request消息中包含NASID/Service-Type及可選的APN屬性，其中Service-Type＝0x02(Framed)表示是地址段請(qǐng)求。

步驟2，Resource-Query-Response消息中攜帶NAS ID(必選)、APN(可選)以及Service-Type AVP(必選)、Framed-Route(必選，承載具體的IP段信息)授權(quán)給NAS，并記錄IP段的分配狀態(tài)以及IP段對(duì)應(yīng)的NAS ID或者APN(如果請(qǐng)求消息中攜帶的話)。其中，F(xiàn)ramed-Route屬性定義如圖6所示。

步驟3，Resource-Free-Request消息用于釋放中包含NASID及可選的APN、Framed-Route屬性。其中Framed-Route為要釋放的地址段，radius服務(wù)器根據(jù)請(qǐng)求中的NASID或NASID+APN標(biāo)記該地址段為未分配狀態(tài)，如果 Framed-Route未攜帶，則radius服務(wù)器釋放該NASID或NASID+APN找到的所有地址段。Radius發(fā)送Resource-Free-Response響應(yīng)消息為可選的。

步驟4，因管理方面原因，radius服務(wù)器可主動(dòng)發(fā)起釋放地址段的請(qǐng)求。Radius服務(wù)器通過發(fā)送Resource-Free-Request消息實(shí)現(xiàn)此目的。消息中攜帶NASID，APN(如果申請(qǐng)時(shí)攜帶)，F(xiàn)ramed-Route(如果攜帶表示釋放指定地址段，如果不指定表示需要其釋放所有地址段)。NAS會(huì)立即發(fā)送響應(yīng)。但radius服務(wù)器需要等收到NAS發(fā)送的Resource-Free-Request請(qǐng)求時(shí)才去真正設(shè)置該地址段為空閑。

步驟5，radius服務(wù)器為保證地址段分配狀態(tài)的時(shí)效性，需要NAS周期性發(fā)送心跳消息，表明正在使用哪些地址段。這在本發(fā)明中通過Resource-Query-Request(Service-Type＝0x12(FramedManagement))實(shí)現(xiàn)。Radius服務(wù)器收到消息后會(huì)更新該地址段的最后報(bào)告時(shí)間，若長時(shí)間收不到報(bào)告，則釋放該地址段資源，狀態(tài)為可分配。

圖7是本發(fā)明實(shí)施例的通過Resource-Query-Request/Reponse消息進(jìn)行地址段申請(qǐng)的信令流程圖，如圖7所示，以在GGSN(NAS)與AAA間Resource-Query-Request/Reponse消息的應(yīng)用進(jìn)行舉例說明，具體包括如下處理：

步驟1，GGSN有地址分配需求，且不存在空閑地址段。

GGSN發(fā)送Resource-Query-Request，攜帶:

NASID＝”nasid01”,

APN＝”apn01”,

Service-Type＝2(Framed),

步驟2，AAA(前文所述radius服務(wù)器的具體化)選擇空閑的地址段，并標(biāo)記為已分配，記錄對(duì)應(yīng)的NASID及APN。

步驟3，AAA發(fā)送Resource-Query-Response，攜帶:

NASID＝”nasid01”,

APN＝”apn01”,

Framed-Route＝”10.1.18.1-10.1.18.50”

綜上所述，借助于本發(fā)明實(shí)施例的技術(shù)方案，通過將原有的地址池劃分為多個(gè)小粒度的地址段，并由地址段狀態(tài)服務(wù)器控制地址段的使用狀態(tài)，在IP地址分配時(shí)，發(fā)送請(qǐng)求消息到地址段狀態(tài)服務(wù)器進(jìn)行地址段申請(qǐng)，解決了現(xiàn)有技術(shù)中預(yù)先分配獨(dú)立地址池時(shí)造成資源分布不均及浪費(fèi)的問題，既可仍由NAS動(dòng)態(tài)分配IP，又可多NAS共享整個(gè)IP地址池。在兼容原網(wǎng)絡(luò)的同時(shí)又避免了集中式分配IP時(shí)性能降低及中斷影響，提高了IP地址資源的利用率。

裝置實(shí)施例

根據(jù)本發(fā)明的實(shí)施例，提供了一種IP地址分配裝置，設(shè)置于網(wǎng)絡(luò)接入服務(wù)器NAS，圖8是本發(fā)明實(shí)施例的IP地址分配裝置的結(jié)構(gòu)示意圖，如圖8所示，根據(jù)本發(fā)明實(shí)施例的IP地址分配裝置包括：劃分模塊80、分配模塊82，以下對(duì)本發(fā)明實(shí)施例的各個(gè)模塊進(jìn)行詳細(xì)的說明。

劃分模塊80，用于預(yù)先將其原有的地址池劃分為多個(gè)小粒度的地址段，并將劃分后的地址段信息保存到地址段狀態(tài)服務(wù)器；

分配模塊82，用于在進(jìn)行IP地址申請(qǐng)時(shí)，如果本地不存在已經(jīng)申請(qǐng)的地址段，或者本地存在已申請(qǐng)的地址段但該地址段中沒有空閑IP地址，則向地址段狀態(tài)服務(wù)器申請(qǐng)一個(gè)新地址段，從新地址段中為NAS進(jìn)行IP地址分配。

優(yōu)選地，上述分配模塊進(jìn)一步用于：如果本地存在已申請(qǐng)的地址段并該地址段中含有空閑IP地址，則直接從該地址段中為NAS進(jìn)行IP地址分配。

優(yōu)選地，上述裝置進(jìn)一步包括：

第一釋放模塊，用于在用戶釋放IP地址后，如果整個(gè)地址段中所有的IP地址均空閑，則釋放該地址段并通知地址段狀態(tài)服務(wù)器。

第二釋放模塊，用于在接收到地址段狀態(tài)服務(wù)器發(fā)送的釋放地址段請(qǐng)求后，釋放相應(yīng)的用戶會(huì)話及IP地址。

發(fā)送模塊，用于周期性向地址段狀態(tài)服務(wù)器發(fā)送地址段使用情況心跳消息；地址段狀態(tài)服務(wù)器在預(yù)定時(shí)間段內(nèi)沒有收到地址段使用情況心跳消息，則 將相應(yīng)的地址段設(shè)置為空閑可分配狀態(tài)。

本發(fā)明實(shí)施例各個(gè)模塊的處理可以根據(jù)上述方法實(shí)施例中的描述進(jìn)行理解，在此不再贅述。

綜上所述，借助于本發(fā)明實(shí)施例的技術(shù)方案，通過將原有的地址池劃分為多個(gè)小粒度的地址段，并由地址段狀態(tài)服務(wù)器控制地址段的使用狀態(tài)，在IP地址分配時(shí)，發(fā)送請(qǐng)求消息到地址段狀態(tài)服務(wù)器進(jìn)行地址段申請(qǐng)，解決了現(xiàn)有技術(shù)中預(yù)先分配獨(dú)立地址池時(shí)造成資源分布不均及浪費(fèi)的問題，既可仍由NAS動(dòng)態(tài)分配IP，又可多NAS共享整個(gè)IP地址池。在兼容原網(wǎng)絡(luò)的同時(shí)又避免了集中式分配IP時(shí)性能降低及中斷影響，提高了IP地址資源的利用率。

顯然，本領(lǐng)域的技術(shù)人員可以對(duì)本發(fā)明進(jìn)行各種改動(dòng)和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動(dòng)和變型在內(nèi)。

在此提供的算法和顯示不與任何特定計(jì)算機(jī)、虛擬系統(tǒng)或者其它設(shè)備固有相關(guān)。各種通用系統(tǒng)也可以與基于在此的示教一起使用。根據(jù)上面的描述，構(gòu)造這類系統(tǒng)所要求的結(jié)構(gòu)是顯而易見的。此外，本發(fā)明也不針對(duì)任何特定編程語言。應(yīng)當(dāng)明白，可以利用各種編程語言實(shí)現(xiàn)在此描述的本發(fā)明的內(nèi)容，并且上面對(duì)特定語言所做的描述是為了披露本發(fā)明的最佳實(shí)施方式。

在此處所提供的說明書中，說明了大量具體細(xì)節(jié)。然而，能夠理解，本發(fā)明的實(shí)施例可以在沒有這些具體細(xì)節(jié)的情況下實(shí)踐。在一些實(shí)例中，并未詳細(xì)示出公知的方法、結(jié)構(gòu)和技術(shù)，以便不模糊對(duì)本說明書的理解。

類似地，應(yīng)當(dāng)理解，為了精簡本公開并幫助理解各個(gè)發(fā)明方面中的一個(gè)或多個(gè)，在上面對(duì)本發(fā)明的示例性實(shí)施例的描述中，本發(fā)明的各個(gè)特征有時(shí)被一起分組到單個(gè)實(shí)施例、圖、或者對(duì)其的描述中。然而，并不應(yīng)將該公開的方法解釋成反映如下意圖：即所要求保護(hù)的本發(fā)明要求比在每個(gè)權(quán)利要求中所明確記載的特征更多的特征。更確切地說，如下面的權(quán)利要求書所反映的那樣，發(fā)明方面在于少于前面公開的單個(gè)實(shí)施例的所有特征。因此，遵循具體實(shí)施方式 的權(quán)利要求書由此明確地并入該具體實(shí)施方式，其中每個(gè)權(quán)利要求本身都作為本發(fā)明的單獨(dú)實(shí)施例。

本領(lǐng)域那些技術(shù)人員可以理解，可以對(duì)實(shí)施例中的客戶端中的模塊進(jìn)行自適應(yīng)性地改變并且把它們?cè)O(shè)置在與該實(shí)施例不同的一個(gè)或多個(gè)客戶端中?？梢园褜?shí)施例中的模塊組合成一個(gè)模塊，以及此外可以把它們分成多個(gè)子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對(duì)本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者客戶端的所有過程或單元進(jìn)行組合。除非另外明確陳述，本說明書(包括伴隨的權(quán)利要求、摘要和附圖)中公開的每個(gè)特征可以由提供相同、等同或相似目的的替代特征來代替。

此外，本領(lǐng)域的技術(shù)人員能夠理解，盡管在此所述的一些實(shí)施例包括其它實(shí)施例中所包括的某些特征而不是其它特征，但是不同實(shí)施例的特征的組合意味著處于本發(fā)明的范圍之內(nèi)并且形成不同的實(shí)施例。例如，在下面的權(quán)利要求書中，所要求保護(hù)的實(shí)施例的任意之一都可以以任意的組合方式來使用。

本發(fā)明的各個(gè)部件實(shí)施例可以以硬件實(shí)現(xiàn)，或者以在一個(gè)或者多個(gè)處理器上運(yùn)行的軟件模塊實(shí)現(xiàn)，或者以它們的組合實(shí)現(xiàn)。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，可以在實(shí)踐中使用微處理器或者數(shù)字信號(hào)處理器(DSP)來實(shí)現(xiàn)根據(jù)本發(fā)明實(shí)施例的加載有排序網(wǎng)址的客戶端中的一些或者全部部件的一些或者全部功能。本發(fā)明還可以實(shí)現(xiàn)為用于執(zhí)行這里所描述的方法的一部分或者全部的設(shè)備或者裝置程序(例如，計(jì)算機(jī)程序和計(jì)算機(jī)程序產(chǎn)品)。這樣的實(shí)現(xiàn)本發(fā)明的程序可以存儲(chǔ)在計(jì)算機(jī)可讀介質(zhì)上，或者可以具有一個(gè)或者多個(gè)信號(hào)的形式。這樣的信號(hào)可以從因特網(wǎng)網(wǎng)站上下載得到，或者在載體信號(hào)上提供，或者以任何其他形式提供。

應(yīng)該注意的是上述實(shí)施例對(duì)本發(fā)明進(jìn)行說明而不是對(duì)本發(fā)明進(jìn)行限制，并且本領(lǐng)域技術(shù)人員在不脫離所附權(quán)利要求的范圍的情況下可設(shè)計(jì)出替換實(shí)施例。在權(quán)利要求中，不應(yīng)將位于括號(hào)之間的任何參考符號(hào)構(gòu)造成對(duì)權(quán)利要求的 限制。單詞“包含”不排除存在未列在權(quán)利要求中的元件或步驟。位于元件之前的單詞“一”或“一個(gè)”不排除存在多個(gè)這樣的元件。本發(fā)明可以借助于包括有若干不同元件的硬件以及借助于適當(dāng)編程的計(jì)算機(jī)來實(shí)現(xiàn)。在列舉了若干裝置的單元權(quán)利要求中，這些裝置中的若干個(gè)可以是通過同一個(gè)硬件項(xiàng)來具體體現(xiàn)。單詞第一、第二、以及第三等的使用不表示任何順序?？蓪⑦@些單詞解釋為名稱。