2.5.4.1 . Định nghĩa PSI- Phõn loại PSI
Khụng giống nhưđịnh danh người dựng chung được cấp phỏt cho người dựng, một PSI là một định danh được cấp phỏt cho một dịch vụ được đăng cai ở mỏy chủ ứng dụng. Vớ dụ, một mỏy chủứng dụng đăng cai một chat room được định danh bởi một PSI. giống như định danh người dựng chung, PSIs cú thể cú dạng SIP URI hay TEL URI.
Khụng giống định danh người dựng chung là PSI khụng liờn quan đến định danh người dựng riờng. Sở dĩ như vậy là vỡ định danh người dựng riờng chỉ sử dụng cho mục đớch nhận thực người dựng. PSIs khụng khụng ỏp dụng cho người dựng.
PSI được chứa trong HSS dưới dạng hoặc là PSI đặc trưng hoặc wildcarded PSI. Một PSI đặc trưng (distinct PSI) cú chứa PSI được sử dụng trong quỏ trỡnh định tuyến, trong khi wildcards PSI là một tập hợp cỏc PSI. wildcards PSI cho phộp ối ưu hoạt động và duy trỡ cỏc nỳt. Một wildcards PSI cú chứa hơn 2 dấu chấm cảm sẽ được xem như một cặp dấu ngăn cỏch.
Khi được chứa trong HSS, wildcarded PSI sẽ bao gồm cả cỏc kớ tự ngăn cỏch
để xỏc định phần mở rộng của PSI.
Vớ dụ : PSI sau cú thể chứa trong HSS "sip:chatlist!.*!@example.com".
Vớ dụ cỏc PSI sau giao tiếp trờn cỏc giao diện bản tin tới HSS sẽ được đổi thành "sip:chatlist!.*!@example.com". khi chứa trong HSS :
sip:chatlist1@example.com
sip:chatlist2@example.com
sip:chatlist42@example.com
sip:chatlistAbC@example.com
sip:chatlist!1@example.com
2.5.4.2. Nguyờn lý Cấu hỡnh và định tuyến cho định danh dịch vụ cụng
cộng
Dựa trờn một loại dịch vụ, cỏc cơ chế khỏc nhau cú thể sử cú thể sử dụng để
cấu hỡnh và định tuyến PSI dựa trờn sự preference của nhà cung cấp dịch vụ
Khi PSI được tạo ra, thỡ sự duy nhất của PSI cần được đảm bảo. Chỳ ý rằng chỉ cú phần username của PSI là được định nghĩa trước
Bất cứ khi nào cú thể, định tuyến đến và đi một PSI cú thể được cung cấp bằng cỏch sử dụng cỏc nguyờn tắc cơ bản trong định tuyến IMS.
2.5.4.2.1. PSI ở phớa khởi tạo
Mỏy chủứng dụng cung cấp dịch vụ PSI cú thể bị kớch hoạt như là một mỏy chủứng dụng khởi tạo. Nú cú thểđược thực hiện thụng qua việc thay đổi thụng
tin lọc trong thụng tin thuờ bao của người dựng sử dụng dịch vụ được xỏc định bởi PSI. Sau đú PSI cú thểđược sử dụng bởi những người dựng này.
Bản tin SIP yờu cầu cú thể được định tuyến tới mỏy chủ ứng dụng tương ứng đăng cai dịch vụ tựy theo cỏc quy tắc lọc khởi tạo trong S-CSCF của người dựng đang sử dụng dịch vụ.
Những PSI được cấu hỡnh tĩnh trước này chỉ cú thể được truy nhập nội bộ từ trong miền IMS của nhà cung cấp dịch vụ mà PSI được cấu hỡnh.
2.5.4.2.2. PSI ở phớa kết thỳc :
Mỏy chủứng dụng đăng cai dịch vụ PSI cú thểđược kớch hoạt như là mỏy chủ ứng dụng kết thỳc thụng qua thụng tin chứa trong HSS. Những PSI na cú khả năng
định tuyến toàn cục và cú thể sẵn sàng sử dụng với người dựng trong và ngoài miền nhà cung cấp và cú thể lấy một trong cỏc dạng sau:
PSI đặc trưng được định nghĩa trong TS 23.003. PSI này cú thể được tạo ra, sửa chữa và xúa trong HSS bởi nhà cung cấp thụng qua cơ chế
o&m(vận hành và bảo dưỡng). PSI cũng cú thểđược tạo ra và xúa bởi người dựng sử dụng giao diện Ut.
PSI đặc trưng cú thểđược kớch hoạt trong HSS bởi mỏy chủ ứng dụng sử dụng giao diện Sh.
Wildcarded PSI cú thể được tạo, sửa chữa và xúa trong HSS bởi nhà cung cấp dịch vụ thụng qua cơ chế vận hành và bảo dưỡng.
Đối với cả distinct PSI và wildcarded PSI, cú hai cỏch để định tuyến tới AS đăng cai PSI:
HSS chứa thụng tin gỏn S-CSCF và thụng tin về tiờu chớ lọc cho “người dung PSI” cú thểđịnh tuyến đến mỏy chủứng dụng cú đăng cai PSI dựa trờn nguyờn tắc định tuyến của IMS. Trong trường hợp này, I-CSCF nhận bản tin SIP yờu cầu ở phớa kết thỳc, truy vấn cơ sở dữ liệu HSS và định tuyến bản tin yờu cầu tới S-CSCF được gỏn cho người dựng PSI. S-
CSCF chuyển tiếp phiờn tới Server ứng dụng cú đăng cai dịch vụ được
định danh bởi PSI dựa vào tiờu chớ lọc cuối cựng.
Hỡnh 2.13 Phiờn đến, định tuyến trực tiếp tới mỏy chủứng dụng
HSS chứa thụng tin địa chỉ của mỏy chủứng dụng đăng cai dịch vụ PSI cho người dựng PSI. Trong trường hợp này, mỏy chủứng dụng xỏc định thụng tin cho PSI và trả lại cho I-CSCF vị trớ đỏp ứng truy vấn, trong trường hợp này I-CSCF sẽ chuyển tiếp yờu cầu trực tiếp đến mỏy chủ ứng dụng đăng cai dịch vụ.
Hỡnh 2.14 Phiờn đến, được định tuyến giỏn tiếp tới AS thụng qua S-CSCF
2.6. Tiờu chớ lọc
Tiờu chớ lọc là một trong những phần quan trọng nhất của thụng tin người dựng được lưu trữ trờn mạng vỡ chỳng xỏc định dịch vụ nào sẽ cung cấp cho họ. Tiờu chớ lọc bao gồm tập hợp cỏc thụng tin liờn quan đến người dựng giỳp cho S-CSCF quyết định khi nào gọi mỏy chủứng dụng cung cấp dịch vụ.
Theo chuẩn 3GPP TS 23.218, cú hai tập tiờu chuẩn lọc là: tiờu chuẩn lọc khởi tạo (initial filter criteria iFC) và tiờu chuẩn lọc kế tiếp (subsequent filter criteria sFC). Tuy nhiờn mới chỉ cú iFC được sử dụng, cũn sFC vẫn cũn nằm trong lý thuyết do nếu ỏp dụng sFC tại S_CSCF sẽ gõy ra xung đột với qui tắc định tuyến bản tin SIP cho cỏc proxy.
Tiờu chớ lọc khởi tạo cú nhiệm vụ đỏnh giỏ cỏc yờu cầu SIP khởi tạo và tạo ra một hội thoại (dialog) hoặc là một yờu cầu đơn. Vớ dụ như S-CSCF đỏnh giỏ tiờu chớ
hoặc bất cứ yờu cầu nào tạo ra cuộc hội thoại hoặc được gửi ngoài cỏc hội thoại. S-
CSCF sẽ khụng đỏnh giỏ tiờu chớ lọc khởi tạo nếu nú nhận yờu cầu PRACK,
NOTIFY, UPDATE hoặc BYE do chỳng luụn được gửi như một phần của một hội thoại SIP đó chấm dứt.
Lý thuyết về tiờu chuẩn lọc kế tiếp là S-CSCF sẽđỏnh giỏ tiờu chớ lọc kế tiếp khi nú nhận được yờu cầu kế tiếp trong một hội thoại SIP. Kết quả của việc đỏnh giỏ này cú thể dẫn đến việc S-CSCF chuyển tiếp yờu cầu SIP kế tiếp đến một mỏy chủ ứng dụng, điều này trỏi ngược với thủ tục định tuyến cho yờu cầu kế tiếp trong SIP proxy. Hơn nữa, trong sự kiện một mỏy chủứng dụng nhận được yờu cầu kế tiếp này, lỳc đú mỏy chủ ứng dụng vẫn chưa nhận được yờu cầu khởi tạo để tạo hội thoại SIP. Do đú mỏy chủ ứng dụng sẽ hủy yờu cầu và bỏ qua. Từ đú dẫn đến việc khụng sử
dụng tiờu chớ lọc kế tiếp trong thực tế.
Tiờu chớ lọc duy nhất được sử dụng là tiờu chớ lọc khởi tạo. Do tiờu chớ lọc kế
tiếp khụng tồn tại nờn thuật ngữ tiờu chớ lọc khởi tạo và tiờu chớ lọc là như nhau. HSS chứa tất cả dữ liệu liờn quan đến người dựng trong một kiến trỳc dữ liệu tờn là user profile. Hỡnh dưới chỉ ra cấu trỳc đơn giản cấp cao của user profile. Ta cú thể thấy user profile cú chứa định danh riờng thuờ bao mà user profile này thuộc về
và một hay nhiều service profile. Mỗi service profile chứa một hay nhiều định danh cụng cộng thuờ bao mà service profile thuộc về và khụng hay nhiều tiờuchuẩn lọc.
Hỡnh 2.15 Cấu trỳc của một User Profile
Khi một thuờ bao đăng ký với S-CSCF, SCSCF sẽ liờn lạc với HSS để tải về
user profile cú chứa cỏc tiờu chuẩn lọc. Vậy tiờu chuẩn lọc sẵn sàng cho S-CSCF khi thuờ bao đăng ký.
Tiờu chuẩn lọc xỏc định dịch vụđược đặt cho nhúm định danh cụng cộng thuờ bao liệt kờ trong service profile. Cấu trỳc dữ liệu của tiờu chuẩn lọc thể hiện ở hỡnh 2- 16.
Hỡnh 2.16 Tiờu chớ lọc khởi tạo
Trường đầu tiờn trong cấu trỳc của tiờu chuẩn lọc là Priority. Trường Priority xỏc định thứ tự của tiờu chuẩn lọc sẽ được dựng so với cỏc tiờu chuẩn lọc cũn lại trong cựng một service profile. S-CSCF trước tiờn sẽ chọn tiờu chuẩn lọc cú độ ưu tiờn cao nhất (độ ưu tiờn 1 là độ ưu tiờn cao nhất). Sau khi thực thi nú, S-CSCF sẽ
tiếp tục với cỏc tiờu chuẩn lọc tiếp theo cú độ ưu tiờn nhỏ hơn. Trường Priority trong tiờu chuẩn lọc là số duy nhất trong cỏc tiờu chuẩn lọc trong cựng một service profile. Với một số trường hợp, sốưu tiờn khụng cần thiết phải là số liền nhau.
Sau trường Priority là khụng hay nhiều Trigger Points (điểm kớch hoạt). Một Trigger Point là một biểu thức cần được đỏnh giỏ để xỏc định xem yờu cầu SIP cú
được phộp chuyển tiếp đến mỏy chủứng dụng hay khụng. Một Trigger Point là tập hợp của cỏc bộ lọc riờng biệt được gọi là Service Point Triggers. Vớ dụ một Trigger Point cú thể như sau:
Trong vớ dụ này cú hai Service Point Triggers là (Method = INVITE) và (Request-URI = sip:user@example.com).
Service Point Triggers cho phộp ta truy nhập vào thụng tin chứa trong cỏc
trường khỏc nhau trong yờu cầu SIP:
Giỏ trị của Request-URI
Yờu cầu SIP (INVITE, OPTIONS, SUBSCRIBE,…)
Sự cú mặt hay vắng mặt của bất cứ header SIP.
Trựng một phần hay toàn bộ nội dung của bất kỳ header SIP.
Trường hợp phiờn (vớ dụ yờu cầu SIP cú nguồn là một thuờ bao được phục vụ, gửi đến thuờ bao đó đăng ký, gửi đến thuờ bao chưa đăng ký).
Mụ tả phiờn (vớ dụ như là trựng một phần hay toàn bộ của bất cứ dũng SDP nào).
Nếu khụng cú Trigger Point thỡ cỏc yờu cầu SIP được chuyển tiếp đến AS vụ
điều kiện.
Sau Trigger Point (chứa một hay nhiều Service Point Triggers), tiờu chuẩn khởi tạo cú AS SIP URI. Đõy là địa chỉ mỏy chủ ứng dụng sẽ nhận yờu cầu SIP nếu cỏc điều kiện được mụ tả trong Trigger Points được thỏa món. Trường Default Handling chỉ hành động khi S-CSCF với lý do nào đú khụng thể liờn lạc được với AS. Một hành động cú thể cú là tiếp tục xử lý yờu cầu SIP hoặc dừng nú lại.
Trường Service Information chứa một số thụng tin trong suốt (trong suốt ở đõy đối với HSS và S-CSCF) mà AS cú thể cần để xử lý yờu cầu. Cỏch sử dụng của trường này được giới hạn cho yờu cầu SIP REGISTER hoặc cỏc yờu cầu khỏc khi mà S-CSCF hoạt động như một SIP User Agent Client. Nguyờn nhõn là do cỏc dữ liệu này được thờm vào phần than cảu yờu cầu SIP. Hành động này khụng được cho phộp
ở cỏc SIP proxy. Do vậy, trường hợp duy nhất sử dụng thụng tin này là khi S-CSCF, tựy theo tiờu chuẩn khởi tạo, hoạt động như một SIP User Agent Client tạo ra yờu cầu SIP REGISTER bờn thứ ba tới AS. Cỏc yờu cầu REGISTER đú cú thể chứa Service
Information (nếu AS cần đến nú), cú nhiệm vụ truyền IMSI tới IM-SSF của thuờ bao
để IMSI cú thểđược dừng bỏi IM-SSF.
Cuối cựng, user profile được mó húa sử dụng Extensible Markup Language
(XML). Mẫu XML định nghĩa tiờu chuẩn lọc được mụ tả trong TS 29.228 (xem thờm
ở phần phụ lục). Tiờu chuẩn lọc khởi tạo được truyền từ HSS tới S-CSCF thụng qua bản tin Diameter.
CHƯƠNG III: MÁY CHỦ ỨNG DỤNG TRONG IMS
3.1. Chức năng của mỏy chủứng dụng (AS)
Cần nhớ luụn nhớ rằng, AS khụng phải là cỏc thực thể IMS thuần tỳy, mà hơn thế nú hoạt động ở lớp trờn cựng trong kiến trỳc phõn tầng IMS. AS là một engine phần mềm thực hiện cỏc ứng dụng cho cỏc mỏy tớnh hoặc thiết bị client thụng qua Internet và sử dụng HTTP.
Hỡnh 3.1 Kiến trỳc phõn tầng IMS
Tuy nhiờn, AS được mụ tảở đõy như là một phần chức năng của IMS vỡ AS là cỏc thực thể cung cấp cỏc dịch vụ multimedia trong kiến trỳc IMS, như là Presence và Push to Talk trờn nền mạng tế bào. Chức năng của AS là :
Khả năng xử lý và tỏc động đến cỏ phiờn SIP nhận được từ IMS.
Khả năng khởi tạo cỏc yờu cầu SIP
Khả năng gửi cỏc thụng tin thanh toỏn để thực hiện chức năng tớnh cước.
Giỏ trị chớnh của IMS trong lĩnh vực dịch vụ là sự kết hợp tiềm năng của cỏc dịch vụ trờn Internet với cỏc dịch vụ truyền thụng truyền thống và dịch vụ
multimedia mới. IMS cho phộp cung cấp sự truy nhập ở mọi nơi vào tất cả cỏc dịch vụ này nhưng cú sự cung cấp cỏc giỏ trị mới tương ứng, như bảo mật, và QoS trong miền truy nhập và cơ chế tớnh cước linh động. Cỏc dịch vụ được cung cấp trờn cỏc AS, cỏc AS này cú thể được đưa vào kiến trỳc IMS bằng cỏch định nghĩa cỏc giao diện tớnh cước, quản lý và điều khiển chuyờn dụng. Một AS cú thể là tận hiến cho một dịch vụ và một người dựng cũng cú thể cú nhiều hơn một dịch vụ, và như vậy rất cú thể sẽ cú một hay một vài AS cung cấp cho một thuờ bao. Thờm vào đú, cũng cú thể cú một hay một vài AS liờn quan tới một phiờn. Vớ dụ như, một nhà cung cấp cú thể cú một AS để điều khiển việc kết thỳc lưu lượng tới người dựng dựa trờn sở
thớch của người dựng đú ( Vớ dụ như chuyển hướng tất cả cỏc phiờn multimedia tới mỏy trả lời tự động trong khoảng từ 5 p.m đển 7a.m) và một AS khỏc để làm thớch nghi nội dung của tin nhắn tựy theo năng lực của của thiết bị người dựng (kớch thước màn hỡnh, độ phõn giải…).
SIP AS là phần liờn quan đến dịch vụ trong IMS. Cỏc API đó được định nghĩa cho phộp cỏc nhà phỏt triển sử dụng hầu hết cỏc mụ hỡnh lập trỡnh. SIP AS
được kớch hoạt bởi S-CSCF, S-CSCF sẽ định hướng cỏc phiờn cụ thể đến SIP AS dựa trờn cỏc thụng tin lọc đạt được từ HSS. Sau đú dựa trờn cỏc nguyờn tắc lựa chọn của mỡnh, SIP AS sẽ quyết định cỏc ứng dụng nào sẽ được triển khai trờn AS tương ứng, cỏc ASnày được SIP AS lựa chọn để điều khiển phiờn. Trong suốt quỏ trỡnh thực thi cỏc logic dịch vụ, SIP AS cũng cú thể giao tiếp với HSS để truy nhập cỏc thụng tin bổ sung liờn quan đến thuờ bao.
3.2. Cỏc chế độ hoạt động của mỏy chủứng dụng:
Từ gúc độ của SIP thỡ một AS cú thểđúng vai trũ như là originating
(terminating) UA, SIP Proxy AS, SIP redirect AS hoặc SIP B2BUA (Back-to-Back
3.2.1. AS hoạt động như SIP UA
Hỡnh 3.2 AS hoạt động như SIP UA
Thiết bị đầu cuối gửi một bản request INVITE tới originating P-CSCF va originating S-CSCF.S-CSCF quyết định chuyển tiếp bản tin tới một AS. AS này hoạt
động như một SIP UA và trả lời bằng bản tin 200 OK response mà được gửi qua S- CSCF và P-CSCF tới thiết bị đầu cuối. Một vớ dụ của dịch vụ mà sử dụng mụ hỡnh này là bất ký dịch vụ nào mà yờu cầu một AS xử lý cỏc bản tin SIP thay cho một người dựng. Mụ hỡnh này được sử dụng trong dịch vụ presence
3.2.2. AS hoạt đụng như một Back-to-Back User Agent
Một B2BUA chỉ đơn giản là hai SIP UA kết nối với nhau .Hỡnh 3.3 chỉ ra cấu trỳc logic của một B2BUA.
Hỡnh 3.4 AS ứng dụng đúng vai trũ SIP B2BUA
Một request A được nhận tại một bờn của UA, sẽ đi qua phần logic dịch vụ đặc trưng.Logic dịch vụ đặc trưng chịu trỏch nhiệm tạo ra response A và tạo ra một request B mới.Logic dịch vụ đặc trưng cú thể thay đổi cỏc trường mà SIP Proxy AS khụng thể thay đổi như To, From, Call-ID,...thậm chớ thay đổi cả method.
Một vớ dụ của cấu hỡnh này là AS đúng vai trũ là prepaid AS. Trong một