Mụ hỡnh dữ liệu này cung cấp một mụ hỡnh ỏnh xạ cỏc tuple tới cỏc hệ thống giao tiếp SIP. Trung tõm của mụ hỡnh là ba bộ phận của thực thể presentity.
• Service: một phục vụ liờn lạc, như install message hoặc điện thoại. là hệ thống cho tương tỏc giữa người sử dụng.
• Device: một thiết bị liờn lạc vật lớ được người sử dụng để làm hoặc nhận một cuộc gọi. Vớ dụ như là điện thoại, thiết bị trợ giỳp cỏ nhõn….
• Person: người sử dụng cuối, và cho mục đớch của presence, là được mụ tả bởi trạng thỏi, như là “busy” hoặc “sad”…
Hỡnh 4.3 miờu tả mụ hỡnh dữ liệu presence. Mụ hỡnh xột một thực thể presence hoặc presentity như miờu tả bởi bốn thành phần dữ liệu khỏc nhau: “presentity URI”, “person”, “service”, “device”. Với mỗi một thành phần (mở rộng cho “presentity URI”) chứa đựng một số dữ liệu kết hợp với person, service, hoặc thiết bị. Mụ hỡnh dữ liệu trạng thỏi người dựng nhấn mạnh tầm quan trọng của bỏo cỏo dữ liệu trạng thỏi người dựng.
Mụ hỡnh dữ liệu trạng thỏi người dựng cho SIP coi mỗi presentity cú thể cú một hoặc nhiều presentity URIs. Trường hợp phổ biến là một presentity là được miờu tả
với một pres URI (được chỉ ra ở RFC 3859[184]) và SIP URI.
Thành phần dữ liệu person cung cấp thụng tin về bản thõn người sử dụng. Hai khớa cạnh được xem xột là: cấu thành bộ phận của người và trạng thỏi của họ (status). Cấu thành bộ phận tham chiếu tới dữ liệu người sử dụng tĩnh (cỏi mà khụng thay đổi với thời gian), vớ dụ như birthday hoặn height. Status tham chiếu tới thụng tin động về người sử dụng, vớ dụ như cỏc hoạt động của người sử dụng ( người sử dụng đang sử dụng phone, trong cuộc họp). Hoặc mood ( người sử dụng đang “sad”,”happy”..). Mụ hỡnh dữ liệu trạng thỏi cho SIP chỉ cho duy nhất một thành phần dữ liệu person trờn một presentity, mặc dự nú cho phộp thành phần person tham chiếu tới một cỏi gỡ đú mà được đối xử như person nhưng khụng phải là person. Vớ dụ như một nhúm người giỳp đỡ trong một trung tõm cuộc gọi.
Hỡnh 4.3 Mụ hỡnh dữ liệu presence cho SIP
Cỏc presentity truy nhập phục vụ, và sự sẵn dàng của cỏc presentity để liờn lạc với một vài phục vụ là được làm mụ hỡnh với thành phần dữ liệu service. Một phục vụ cú thể bao gồm videotelephony, push-to-talk, instant message,..Giống như thành phần dữ liệu person, thành phần dữ liệu service cú thểđược miờu tảở mục cấu thành bộ phận (dữ liệu phục vụ tĩnh) và trạng thỏi (status). Vớ dụ về dữ liệu phục vụ tĩnh đú là: SIP được cung cấp bởi phục vụ hoặc cỏc khả năng khỏc cỏi mà miờu tảở dịch vụ
như audio, video.
Thành phần dữ liệu device. Cũng giống như service và person, cỏ thiết bị được miờu tảở mục cấu thành bộ phận và status. Vớ dụ như là kớch thước hiển thị, số lượng màu, status như là năng lượng pin cũn lại…
4.4. SIP và cỏc thủ tục để thực hiện dịch vụ presence trong IMS
SIP đó được mở rộng cho trạng thỏi người dựng với việc tạo ra gúi sự kiện gọi là presence. Khi đăng ký đến một sự kiện như thế, thuờ bao sẽ thiết lập giỏ trị
“presence” trong trường header Event.
Một vài định nghĩa được tạo ra để tạo ra dịch vụ:
• Presentity: Là thực thể cung cấp thụng tin trạng thỏi người dựng
(presence)
• Watcher : Là thực thể yờu cầu thụng tin trạng thỏi của một presentity khỏc từ Presence Server, watcher cú thểở trong cựng một mạng chủ hoặc mạng khỏch với presentity
• Presence Server (PS): Là thực thể chấp nhận, chứa đựng thụng tin đưa lờn bởi PUA và sử lớ cỏc yờu cầu đăng kớ nhận thụng tin presence
• Presence User Agent ( PUA): Là thực thể thu thập và cấp thụng tin trạng thỏi tới Presence Server
• Resource List Server (RLS): Mỗi Watcher luụn muốn nhận thụng tin của nhiều presentity. Vớ dụ điển hỡnh là một người dựng Alice cú rất nhiều người bạn và người dựng Alice muốn nhận thụng tin trạng thỏi của những người bạn này. Để trỏnh tỡnh trạng watcher (của người dựng Alice) phải gửi quỏ nhiều bản tin SUBSCRIBE tới từng người bạn, một khỏi niệm mới là danh sỏch nguồn đó được đưa ra. Một danh sỏch nguồn là một danh sỏch của cỏc SIP URIs được lưu trữ trong một thực thể chức năng Resource List Server (RLS). RLS thực hiện dịch vụ URI-list. Danh sỏch nguồn cú một địa chỉ SIP URI của riờng nú ( vớ dụ sip:alice-
list@home1.net). RLS sẽ nhận SUBCRIBE request từ một Watcher và
chuyển tiếp nú tới nhiều presentity.
Một presentity cú thể cú nhiều PUA.Vớ dụ về PUA là ứng dụng được cài trong PDA, trong laptop, trong mobile phone,…
Để truyền tải những thụng tin về trạng thỏi người dựng, mụ hỡnh SIP sử dụng
method NOTIFY. Thõn của NOTIFY request mang thụng tin trạng thỏi.Trong trường
hợp này thụng tin trạng thỏi là trạng thỏi cú mặt của thực thể prenstity. Kiểu MIME của những thụng tin này là “application/pidf + xml” được định nghĩa trong RFC 3863. Những văn bản presence XML cú thể được sử dụng để truyền tải được nhiều thụng tin hơn.
Để xuất ra những thụng tin trạng thỏi người dựng, mụ hỡnh SIP sử dụng method PUBLISH. Trường header Event trong PUBLISH request sẽđược thiết lập giỏ trị là “presence”. Thời gian mặc định của một lần xuất thụng tin là 3600 giõy.
Hỡnh 4.4 Kiến trỳc SIP presence
4.5. Kiến trỳc dịch vụ presence trong IMS
Nhiều thực thể trong mạng IMS cú thể cung cấp cỏc thụng tin trạng thỏi: cú thể
là một PUA ở mạng khỏch, một PUA ở trong một thiết bịđầu cuối hoặc là một PUA
dựng.
.
Hỡnh 4.5 Kiến trỳc để cung cấp dịch vụ presence trong IMS
Watcher Presence Proxy: Là một Proxy cú nhiệm vụ chỉ ra mạng đớch của một presentity và phõn phải địa chỉ của presentity đú.
Presentity Presence Proxy: Chỉ ra Presence Server phõn bổ cho một presentity.
4.6. Giao thức thao tỏc dữ liệu XCAP
Giao thức truy nhập cấu hỡnh XML (XCAP) là giao thức được thiết kế theo
chuẩn HTTP, nú sử dụng phương phỏp HTTP như PUT, GET, DELETE cho việc
giao tiếp trờn điểm thao chiếu Ut. XCAP ỏnh xạ tài liệu XML và cỏc nhõn tố thuộc tớnh tới HTTP URIs, vỡ vậy cỏc thành phần này cú thể được truy nhập trực tiếp bởi cỏc phương phỏp HTTP. XCAP cung cấp một client (ứng dụng) với cỏch thức để
thờm, sửa, xúa cấu hỡnh XML của một loại dữ liệu bất kỳở XCAP server. Trong hoạt
động phục vu dịch vụ presence XCAP server được sử dụng để cho phộp XCAP client thao tỏc dữ liệu: user ở danh sỏch user, chớnh sỏch cấp quyền, hoặc danh sỏch người
.
Hỡnh 4.6 Sử dụng XCAP
Presence server sử dụng tài liệu chứa đựng trong XCAP server theo cấu trỳc: xcap-root
• pres-rules
o users
bob
• presence-rules.xml //file chứa đựng luật cấp phộp presence cho bob
alice • presence-rules.xml ... (thư mục cho người sử dụng khỏc) • resource-lists o users bob
• resource-list.xml //file chứa đựng danh danh sỏch nguồn cho bob
alice
• resource-list.xml
... (thư mục cho người sử dụng khỏc)
• rls-services
o global
Vớ dụ:
• resource-list.xml
• Presence-rules.xml
4.7. Một số luồng bản tin bỏo hiệu cơ bản phục vụ dịch vụ
Luồng tớn hiệu bỏo hiệu phục vụ dịch vụ presence chỉ ra làm như thế nào cỏc watcher cú thể yờu cầu thụng tin trạng thỏi của một thực thể cung cấp thụng tin. Ở đõy ta tập trung nghiờn cứu về cỏc bản tin khởi tạo SUBSCRIBE request đểđăng kớ nhận thụng tin trạng thỏi, và cỏc NOTIFY request khởi tạo chứ khụng nghiờn cứu
cỏc bản tin SUBSCRIBE request và NOTIFY request chuyển tiếp giữa cỏc CSCF.
Một số kớ hiệu để hiểu luồn tớn hiệu:
• Rls.home1.net: một RLS ở home network của watcher.
• Rls.home2.net: một RLS ở home network của nhà cung cấp dịch vụ, khụng ở
• Ps.home1.net: một PS ở home network của bờn xuất bản thụng tin
• Ps.home2.net: một PS ở home network của nhà cung cấp dịch vụ, khụng ở home network của watcher.
• User1_list1@home1.net: một danh sỏch nguồn đang được đăng kớ tới RLS ở
home network.
• User2_list1@home2.net: một danh sỏch nguồn đang được đăng kớ tới RLS ở
home network của nhà cung cấp dịch vụ, khụng ở home network của thuờ bao
đăng kớ.
4.7.1. Watcher đăng kớ để nhận thụng tin trạng thỏi của một thực thể cung cấp thụng tin
4.7.1.1. Watcher ở mạng khỏch đối với thực thể cung cấp thụng tin
Home Network#2 Home Network#1 UE (Watcher) P-CSCF#1 S-CSCF#1 I-CSCF HSS S-CSCF#2 AS(PS) 2.SUBSCRIBE 3.Đỏnh giỏ lọc Khởi tạo 4.SUBSCRIBE 5.Truy vấn vị trớ user 6.SUBSCRIBE 7.Đỏnh giỏ lọc khởi tạo 8.SUBSCRIBE 9.Cấp phộp watcher 10.200(OK) 11.200(OK) 12.200(OK) 13.200(OK) 14.200(OK) 15.NOTIFY 16.NOTIFY 17.NOTIFY 18.200(OK) 19.200(OK) 20.200(OK) 1.SUBSCRIBE
Hỡnh 4.7 chỉ ra watcher đăng kớ để nhận thụng bỏo về sự kiện presence của một thực thểở mạng con IM CN khỏc. Chi tiếp về một số luồng:
• 1. SUBSCRIBE request (UE (watcher) tới P-CSCF) Một watcher muốn nhỡn
thụng tin presence của một thực thể presentity. Để khởi tạo đăng kớ, watcher tạo ra một SUBSCRIBE request chứa đựng trường event (sự kiện) “presence” cựng với trường Expires chỉ ra thời gian hết hạn của một đăng kớ.
• 3 và 7 đỏnh giỏ lọc khởi tạo: S-CSCF#1 và S-CSCF#2 xỏc nhận tớnh hợp lệ
của của service profile của thuờ bao.
• 5 Cx truy vấn vị trớ user đú là I-CSCF gửi một truy vấn tới HSS để tỡm S- CSCF của user được gọi. HSS đỏp ứng lại với vị trớ hiện tại của S-CSCF cho mỗi thuờ bao, chi tiết được miờu tảở 3GPP TS 29.228.
• 9 Cấp phộp watcher đú là: PS thực hiện kiểm tra cấp phộp cần thiết trờn người khởi tạo để chắc chắn rằng nú được cho phộp để nhỡn presentity. Trong vớ dụ
này, tất cả tỡnh trạng bảo mật là được thỏa món, vỡ vậy PS gửi đỏp ứng 200(OK) tới S-CSCF. Trong trường hợp cấp phộp lỗi, khi đú đỏp ứng 2xx
hoặn 4xx sẽđược gửi tới S-CSCF. Sự lựa chọn mó đỏp ứng sửa phụ thuộc vào chớnh sỏch cấp phộp của yờu cầu đăng kớ của presentity.
• 15 NOTIFY request (PS tới S-CSCF) Ngay sau khi PS gửi đỏp ứng 200 (OK)
để chấp nhận sựđăng kớ, nú gửi NOTIFY request với thụng tin presence trạng thỏi hiện tại của presentity mà watcher đăng kớ để nhận. NOTIFY request
được gửi tới S-CSCF#1. Dựa trờn trường Accept của SUBSCRIBE request,
PS quyết định sử dụng một phần thụng bỏo để cung cấp sự thay đổi của thụng tin trạng thỏi.
4.7.1.2. Watcher đăng kớ với RLS để nhận thụng bỏo về thụng tin trạng thỏi người dựng của một danh sỏch nguồn
4.7.1.2.1. RLS nằm trong cựng Home Network với UE
UE (Watcher) P-CSCF S-CSCF AS(RLS) 1.SUBSCRIBE 2.SUBSCRIBE 3.Đỏnh giỏ lọc khởi tạo 4.SUBSCRIBE 5.Cấp phộp Watcher 6.200(OK) 6.200(OK) 7.200(OK) 9.NOTIFY 10.NOTIFY 11.NOTIFY 12.200(OK) 13.200(OK) 14.200(OK) 15.Đăng kớ và thụng bỏo gúi sự kiện presence 16.NOTIFY 18.NOTIFY 19.200(OK) 20.200(OK) 21.200(OK) 17.NOTIFY
Visited Network Home Network of UE
Hỡnh 4.8 Watcher đănng kớ tới danh sỏch nguồn để nhận thụng tin trạng thỏi của danh sỏch người dựng
Hỡnh trờn chỉ ra luồng bản tin bỏo hiệu khi Watcher đăng kớ tới danh sỏch nguồn
để nhõn thụng tin presence trong trường hợp RLS nằm cựng Home Network của UE.
• 1. SUBSCRIBE request (watcher tới P-CSCF) một watcher muốn biết thụng
tin presence của nhiều thực thể presentity. Danh sỏch của cỏc thực thể
presenctity được nhận dạng bởi một SIP URI. Để khởi tạo một đăng kớ tới
RLS phỏp ra một SUBSCRIBE request chỉ ra cung cấp (supported) cho
• 9. NOTIFY request (RLS tới S-CSCF) RLS phỏt ra một NOTYFY request bao gồm tài liệu RLMI như là kết quả của SUBSCRIBE request.
• 15. Đăng kớ và thụng bỏo gúi sự kiện presence: đú là sau khi RLS phỏt ra một NOTIFY request núi cho UE (watcher) biết về trạng thỏi đăng kớ, RLS sẽ phỏt ra một SUBSCRIBE request cần thiết tới cỏc thực thể presentity tồn tại trong danh sỏch nguồn. Ngay sau khi RLS nhận NOTIFY request về sự thay đổi ở
một hoặc nhiều thực thể presentity nú sẽ phỏt ra NOTIFY request.
• 16. NOTIFY request (RLS tới S-CSCF) RLS sao lưu tất cả thõn NOTIFY
request đến vào thõn một NOTIFY request ra sử dụng dạng MIME
một phần thụng tin presence được bật ( chỉ thụng tin presence, cỏi mà đó được thay đổi từ thụng bỏo cuối cựng như miờu tảở RFC 4662 [22]. Ở vớ dụ này giả
sử rằng RLS đó nhận hai NOTIFY request từ cỏc thực thể presentity là
“sip:user2_public1@home2.net” và “sip:user3_public1@home3.net” trước
4.7.1.2.2. RLS ở trong cựng Home Network với AS UE (Watcher) AS(RLS) HSS I-CSCF S-CSCF P-CSCF 1.SUBSCRIBE 2.SUBSCRIBE 3.Đỏnh giỏ lọc khởi tạo 7.Cấp phộp Watcher 10.200(OK) 11.200(OK) 12.NOTIFY 14.NOTIFY 15.200(OK) 16.200(OK) 17.200(OK) 18. Đăng kớ và thụng bỏo gúi sự kiờn
presence 19.NOTIFY 20.NOTIFY 21.NOTIFY 22.200(OK) 23.200(OK) 24.200(OK)
Home Network Home Network of AS
13.NOTIFY
4.SUBSCRIBE 5.Cx truy vấn vị trớ PSI
6.SUBSCRIBE
9.200(OK) 8.200(OK)
Hỡnh 4.9 Watcher đăng kớ tới danh sỏch nguồn để nhận thụng tin trạng thỏi của danh sỏch người dựng
Hỡnh 4.9 chỉ ra luồng bản tin watcher đăng kớ tới danh sỏch nguồn để nhõn thụng tin presence trong trường hợp RLS nằm ở Home Network của AS.
• Cỏc SUBSCRIBE request và NOTIFY request hoạt động tương tự như trương hợp 4.7.1.2.1
• 5 truy vấn vị trớ PSI đú là: I-CSCF gửi truy vấn đến HSS để tỡm vị trớ của RLS. HSS sẽđỏp ứng với địa chỉ của RLS. Chi tiết về luồng bản tin được chỉ
ra ở 3GPP TS 29.228
4.7.2. RLS đăng kớ để nhận thụng tin trạng thỏi của người dựng của một thực thể cung cấp thụng tin ở mạng khỏch S-CSCF I-CSCF HSS S-CSCF AS(PS) AS(RLS) 1.SUBSCRIBE 2.Đỏnh giỏ lọc khởi tạo 2.SUBSCRIBE 4.Cx truy vấn vị trớ user 5.SUBSCRIBE 6.Đỏnh giỏ Lọc khởi tạo 7.SUBSCRIBE 8.Cấp phộp Watcher 9.200(OK) 10.200(OK) 11.200(OK) 12.200(OK) 13.NOTIFY 14.NOTIFY 15.200(OK) 16.200(OK)
List Server Presentity Home Network
Hỡnh 4.10 RLS đăng kớ để nhận thụng tin trạng thỏi của người dựng của một thực thể cung cấp thụng tin ở mạng khỏch
Hỡnh trờn chỉ ra RLS đăng kớ để nhận thụng bỏo về presence của presentity,
presentity là ở mạng IM CN khỏc.Chi tiết về một số luồng:
sự kiện “presence” với tất cả thực thể presentity, cỏi mà được miờu tả bởi danh sỏch nguồn SIP URI. Home Network của cỏc thực thể presentity cú thể khỏc hoặc trong cựng một mạng. Trong luồng tớn hiệu trờn là ở khỏc mạng. Để khởi tạo một đăng kớ, RLS phỏt ra một SUBSCRIBE request chứa đựng sự kiện “presence” cỏi mà nú mong muốn được thụng bỏo, RLS gửi yờu cầu tới S- CSCF.
• 14. NOTIFY request (PS tới S-CSCF) hoạt động tương tự như luồng tớn hiệu ở
chương IV mục 4.7.1.1
4.7.3. Thực thể cung cấp thụng tin cập nhật thụng tin trạng thỏi
UE P-CSCF S-CSCF PS 1.PUBLISH 2.PUBLISH 3.Đỏnh giỏ lọc khởi tạo 4.PUBLISH 5.Cấp phộp xuất bản 6.200(OK) 7.200(OK) 8.200(OK) Home Network Hỡnh 4.11 UE xuất thụng tin trạng thỏi tới PS
UE cú thể xuất một phần hoặc toàn bộ thụng tin presence về một thực thể presentity tới PS. Trong vớ dụ này, giả sử UE xuất toàn bộ thụng tin presence. Hỡnh 4.11 chỉ ra UE xuất thụng tin hoặc thay đổi thụng tin trạng thỏi người dựng đó tồn tại. Một số chi tiết về luồng:
• 1. PUBLISH ( UE tới P-CSCF) Một PUA trong một UE mong muốn xuất
thụng tin presence. Để khởi tạo sự xuất bản, UE phỏt ra một yờu cầu
PUBLISH theo chuẩn RFC 3903 chứa đựng thụng tin presence mà mong
4.7.4. Luồng tớn hiệu hoạt động HTTP phục vụ dịch vụ kiểm tra trạng thỏi người dựng thỏi người dựng
Luồng tớn hiệu này chỉ ra sự thao tỏc dữ liệu phục vụ hoạt động dịch vụ presence tại
điểm thao chiếu Ut sử dụng XCAP. Luồng chỉ chỉ ra luồng tớn hiệu giữa XCAP server và XCAP client, bởi vậy cỏc proxy giữa cỏc thực thể này là khụng được chỉ ra