Sau khi thiết lập PDP Context báo hiệu và dò tìm ra địa chỉ P-CSCF, UE (của tobias trong ví dụ này) gửi yêu cầu REGISTER (1) đến P-CSCF, nó có dạng:
REGISTER sip:homel.fr SIP/2.0
Via: SIP/2.0/UDP [5555: :a:b:c:d];branch=0uetb Route: sip: [5555 : :a:f:f:e];Ir
Max-Forwards: 70 From: <sip:tobias@homel.fr>;tag=pohja To: <sip:tobias@homel.fr> Contact: <sip:[5555::1:2:3:4]>;expires=600000 Call-ID: apb03aOs09dkjdfglkj49111 CSeq: 25 REGISTER Content-Length: 0
Đích đến cuối cùng của yêu cầu này là Registrar (chính là S-CSCF) có địa chỉ: sip:homel.fr (tên miền của mạng thường trú đọc trong ISIM).
Mào đầu To chỉ ra nhận dạng user public (cũng đọc từ ISIM, nhận dạng này giống như
một địa chỉ phục vụ cho dịch vụ. Ví dụđịa chỉ A là dịch vụ nhắn tin và thoại, địa chỉ B là dịch vụ game và video). Địa chỉ này báo cho Registrar biết rằng sip:tobias@home.fr sẽ được dùng với địa chỉ liên lạc chứa ở mào đầu Contact: sip:[5555::1:2:3:4] hạn
Luận văn thạc sĩ kỹ thuật 55
dùng 600000 giây (mạng có thểđiều chỉnh giá trị này cho phù hợp, bằng cách giửi lại giá trị hạn ở phản hồi 200 OK hoàn thành khởi tạo đăng ký).
UE đặt địa chỉ của nó tại mào đầu Via: [5555::a:b:c:d] (mào đầu này thông báo cho nút kế tiếp biết địa chỉ của nút trước mà bản tin đã đi qua, một nút có thể điền thêm hoặc xóa bớt thông tin này để phục vụ cho sự định tuyến). Tham số Branch là nhận dạng của giao dịch (một loạt các bản tin hay thủ tục đáp ứng cho một yêu cầu).
Mào đầu Route chỉ ra địa chỉ của nút kế tiếp (ởđây là P-CSCF). Mào đầu From nhận dạng user đang thực hiện đăng ký.
Mào đầu Call-ID cùng với mào đầu Cseq dùng để nhận dạng giao dịch REGISTER. Content-Length bằng không vì yêu cầu REGISTER không chứa nội dung text.
Sau khi đã đóng gói yêu cầu REGISTER trên (chú ý rằng mỗi gói tin không thể có độ
dài lớn hơn 1300 byte), UE sẽ gửi tới chặng kế tiếp (P-CSCF) theo giao thức UDP. Nếu không có port nào được ấn định trong mào đầu Route thì yêu cầu sẽđược gửi đến port SIP mặc định là 5060.
P-CSCF nhận được yêu cầu REGISTER, nó sẽ nhận ra được UE chưa được nhận thực nên P-CSCF sẽ thực hiện chức năng proxy của nó. P-CSCF sẽ xóa bỏ mào đầu Route của yêu cầu (vì mào đầu này chỉđến chính P-CSCF này) và tiếp tục gửi nó đến chặng kế tiếp, đồng thời thêm vào một mào đầu Via nữa có chứa địa chỉ của P-CSCF này. Để
thực hiện điều này, P-CSCF cần dùng DNS NAPTR (Naming Authority Pointer) , SRV (Service records) và các truy vấn AAA, P-CSCF sẽ tìm ra địa chỉ của I-CSCF trong mạng của Tobias. Sau đó P-CSCF không đặt địa chỉ của I-CSCF vào mào đầu Route, nó sẽđặt địa chỉ của I-CSCF vào gói UDP chứa yêu cầu đó và gửi trực tiếp tới I-CSCF.
REGISTER sip:homel.fr SIP/2.0
Via: SIP/2.0/UDP sip:pcscf l.visitedl.fi;branch=0pctb Via: SIP/2.0/UDP [5555 : :a:b:c:d];branch=0uetb Max-Forwards: 69 From: <sip:tobias@homel.fr>;tag=pohja To: <sip:tobias@homel.fr> Contact: <sip:[5555::1:2:3:4]>;expires=600000 Call-ID: apb03aOs09dkjdfglkj49111 CSeq: 25 REGISTER
Luận văn thạc sĩ kỹ thuật 56
Content-Length: 0
I-CSCF nhận được yêu cầu REGISTER đó, nó sẽ truy vấn HSS để phân công S-CSCF phục vụ cho UE đang đăng ký. Sau đó I-CSCF thêm vào một mào đầu Via chứa địa chỉ của nó rồi gửi yêu cầu tới S-CSCF đã được phân công.
REGISTER sip:homel.fr SIP/2.0
Via: SIP/2.0/UDP sip:icscf 1 .homel.fr;branch=0ictb Via: SIP/2.0/UDP sip:pcscf1.visitedl.fi;branch=0pctb Via: SIP/2.0/UDP [5555::a:b:c:d];branch=0uetb Route: siptscscfl.homel.fr;lr
Max-Forwards: 68
From: <sip:tobias@homel.fr>;tag=pohja To: <sip:tobias@homel.fr>
Contact: <sip: [5555: :1:2:3:4]>;expires = 600000 Call-ID: apb03aOs09dkjdfglkj49111
CSeq: 25 REGISTER Content-Length: 0
Sựđăng ký được thực hiện tại S-CSCF. Sau khi nhận được yêu cầu REGISTER khởi tạo, S-CSCF sẽ yêu cầu Tobias nhận thực (sẽ được mô tả chi tiết ở mục sau). Các thông tin nhận thực sẽđược Tobias trả lời ở yêu cầu REGISTER thứ hai:
REGISTER siprhomel.fr SIP/2 .0
Via: SIP/2 .0/UDP sip: icscf 1 .homel. f r ;branch=3ictb Via: SIP/2 .0/UDP sip :pcscf 1. visitedl.n;branch=2pct Via: SIP/2.0/UDP [5555::a:b:c:d];branch=1uetb Route: sip:scscfl.homel.fr;Ir
Max-Forwards: 67
From: <sip:tobias@homel.fr>;tag=ulkomaa To: <sip:tobias@homel.fr>
Contact: <sip: [5555: :1:2:3:4]>;expires=600000 Call-ID: apb03aOs09dkjdfglkj49222
Luận văn thạc sĩ kỹ thuật 57
Content-Length: 0
Nếu nhận thực thành công, S-CSCF sẽđăng ký phục vụ cho Tobias, đồng thời nó cũng cập nhật thông tin lên HSS chỉ ra trạng thái đăng ký của Tobias.
Sau cùng S-CSCF gửi lại phản hồi 200 OK cho UE, chỉ ra thủ tục đăng ký đã thực hiện thành công:
SIP/2.0 200 OK
Via: SIP/2 .0/UDP icscf1.homel. fr;branch=3ictb Via: SIP/2.0/UDP pcscfl.visitedl.fi;branch=2pctb Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=luetb From: <sip:tobias@homel.fr>;tag=ulkomaa
To : <sip:tobias@homel.fr>;tag=kotimaa
Contact: <sip: [5555: :a:b:c:d]>;expires = 600000 Call-ID: apb03aOs09dkjdfglkj49222
CSeq: 47 REGISTER Content-Length: 0
Nhờ có mào đầu Via, phản hồi sẽ đi qua các CSCF mà yêu cầu đã đi qua để về UE.
Điều đó được thực hiện theo trình tự ngược (mỗi một CSCF mà phản hồi đi qua sẽ
thực hiện xóa đi mào đầu Via của nó).
Chú ý rằng bản tin chứa mào đầu Service-Route để chỉ ra một yêu cầu hoặc một phản hồi thực hiện cho chính người gọi hay cho thiết bị UE của người gọi (khi khởi tạo yêu cầu là người gọi thực hiện qua UE, yêu cầu thứ hai là do UE tựđộng thực hiện), ví dụ: Service-Route sip:orig@scscf1.homel.fr;Ir. Nếu bắt buộc các bản tin phải qua P-CSCF (do cơ chế bảo mật yêu cầu) thì cần có mào đầu Path sẽ chứa địa chỉ của proxy bắt buộc bản tin phải qua đó.
2.2.1.2 Vấn đề nhận thực
2.2.1.2.1 Khái quát sự nhận thực
Hình 2-14 đã mô tả về quá trình đăng ký, trong đó có bao hàm cả sự nhận thực user. Khi S-CSCF nhận được yêu cầu REGISTER đăng ký, nó tải về vector nhận thực AV (authentication vector) từ HSS (bằng cách gửi SAR đến HSS và nhận về SAA, đã đề cập ở mục 2.2.1.1). AV chứa RAND (chuỗi số ngẫu nhiên), XRES (kết quả so sánh với RES từ UE), AUTN (network authentication token), IK (integrity key) và CK
Luận văn thạc sĩ kỹ thuật 58
(ciphering key). S-CSCF sẽ phản hồi bằng cách gửi 401 Unauthorized chứa RAND, AUTN, IK và CK trở lại phía UE.
P-CSCF nhận được phản hồi này, nó sẽ xóa IK và CK rồi gửi phản hồi đến UE. IK
được dùng cho việc kết hợp bảo mật giữa P-CSCF và UE (trình bầy trong vấn đề quản lý phiên).
Sau khi nhận được 401 Unauthoried, UE thẩm tra AUTN dựa trên IK và SQN có trong ISIM. Sự thẩm tra AUTN thành công đồng nghĩa với việc mạng được nhận thực (đảm bảo dữ liệu nhận thực nhận được đúng từ mạng thường trú của UE). UE thực hiện tính toán RES (authentication challenge response) dựa trên CK và RAND, rồi gửi RES ở
yêu cầu REGISTER thứ cấp lại cho S-CSCF. S-CSCF sẽ thực hiện so sánh XRES nhận được từ HSS với RES nhận được từ UE, nếu thành công thì UE được nhận thực và tiếp tục thực hiện các thủ tục khác (các tham số nhận thực sẽ được nằm trong các bản tin khác cho đến khi kết thúc dịch vụ).
2.2.1.2.2 Chi tiết sự nhận thực
Thông tin nhận thực chứa trong yêu cầu REGISTER khởi tạo:
REGISTER sip:homel.fr SIP/2.0
Authorization: Digest username="tobias_private@homel.fr", realm="homel.fr",
nonce="",
uri="sip:homel.fr", response=""
integrity-protected="no"
Mào đầu Authorization chỉ ra nhận dạng user private (là nhận dạng về UE duy nhất,
được S-CSCF và HSS dùng để tìm AV tương ứng với UE đó), Digest chỉ ra cơ chế cho việc tính RES là 3 GPP AKA. Realm xác định miền thường trú. Vì giữa UE và P- CSCF lúc này vẫn chưa thực hiện cơ chế bảo mật nào nên mào đầu integrity-protected có giá trị là “no”.
S-CSCF sau khi nhận được yêu cầu REGISTER, nó dựa vào nhận dạng user private của Tobias để tải về AV từ HSS. Dựa vào AV, S-CSCF sẽ gửi lại phản hồi 401 Unauthorized có mào đầu WWW-Authentiacate, RAND, AUTN, 32 byte và mã hóa Base 64, IK và CK:
SIP/2.0 401 Unauthorized
Luận văn thạc sĩ kỹ thuật 59
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAvl-MD5,
ik="0123456789abcdeedcba9876543210", ck="9876543210abcdeedcba0123456789"
Sau khi P-CSCF nhận được phản hồi này nó sẽ thực hiện xóa đi IK và CK rồi gửi tiếp cho UE.
Từ AUTN và ISIM, UE sẽ nhận ra mạng đã gửi 401 Unauthorized trên có phải là mạng thường trú của UE đó hay không. Nếu đúng, UE sẽ thực hiện tính toán RES dựa vào CK, RAND và AKAv1-MD5 rồi trả về kết quả tại mào đầu Response ở yêu cầu REGISTER thứ cấp, rồi gửi nó đến S-CSCF (chú ý, IK được dùng cho việc kết hợp bảo mật IPsec SAs giữa P-CSCF và UE, vì chỉ P-CSCF và UE biết nên sẽ chống được nghe trộm tại giao diện Gm).
REGISTER sip:homel.fr SIP/2.0
Authorization: Digest username="userl_jprivate@homel. f r " , realm="homel.fr",
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAvl-MD5, uri="sip:homel.fr",
response="6629fae49393a05397450978507c4efl"
P-CSCF nhận được yêu cầu REGISTER thứ cấp, nó sẽ thực hiện kiểm tra tính toàn vẹn của yêu cầu. Nếu thành công, P-CSCF sẽ thêm vào mào đầu intergrity-protected
được lập giá trị là “yes” rồi gửi yêu cầu đến chặng tiếp theo để tới S-CSCF.
REGISTER sip:homel.fr SIP/2.0
Authorization: Digest username="userl_private@homel.fr", realm="homel.fr",
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAvl-MD5, uri="sip:homel.fr",
response="6629fae49393a05397450978507c4efl" , integrity-protected="yes"
Cuối cùng S-CSCF so sánh RES và XRES đểđưa ra quyết định cho sự nhận thực.
2.2.1.3 Vấn đề tính cước
Luận văn thạc sĩ kỹ thuật 60 2.2.1.3.1 Cấu trúc tính cước offline
Hình 2-18: Cấu trúc tính cước offline IMS
Phần tử chức năng trung tâm của cấu trúc tính cước offline là CCF (Charging Collection Function). CCF nhận các thông tin tài khoản từ các thực thể IMS qua giao diện Rf (điểm tham chiếu Rf), xử lý các dữ liệu nhận được thành dạng bản ghi dữ liệu cước CDR (Charging Data Record). CDR sẽ được gửi đến hệ thống tính cước lập hóa
đơn.
CCF có các chức năng chính:
• Thu thập thông tin tài khoản từ các thực thể IMS và tạo thông tin tính cước theo định dạng CDR phù hợp.
• Gửi CDR đến hệ thống tính cước lập hóa đơn.
• Lưu trữ tạm thời CDR nếu hệ thống tính cước lập hóa đơn đang bận.
CCF có thể được triển khai tập trung hay phân tán hoặc là chức năng tích hợp trong các thực thể IMS.
CGF – Charging Gateway Funtion cung cấp cơ chế truyền thông tin tính cước từ
SGSN và GGSN đến các hệ thống tính cước đã được nhà khai thác mạng chọn.
Billing system có nhiệm vụ tạo các hóa đơn để gửi tới thuê bao hàng tháng.
Điểm tham chiếu Rf
Thông tin tính cước được gửi từ các thực thể IMS đến CCF nhờ các yêu cầu Diameter Accounting (ACR) qua giao diện Rf. Tất cả các thực thể liên quan đến quản lý phiên
Luận văn thạc sĩ kỹ thuật 61
(ví dụ I-CSCF) gửi các Session ACR (được gửi thông báo về trạng thái bắt đầu, chuyển tiếp, kết thúc phiên ở các CDR). Các thực thể liên quan đến việc điều khiển phiên (như MRFC) gửi các Event ACR (gửi thông báo chung).
Bất cứ khi nào nhận được SIP 200 OK hoặc MRFC nhận được ISUP answer, thì ACR start được gửi đến CCF. Và bất cứ khi nào nhận được SIP BYE hoặc MGCF nhận
được ISUP Release, thì ACR stop được gửi đến CCF.
Bảng 2-4: Bảng tham chiếu các bản tin tính cước offline
Tên lệnh Mục đích Viết tắt Nguồn Đích Yêu cầu tính cước ACR được sử dụng để báo cáo/dừng thông tin tính cước tới CCF ACR S-CSCF, I- CSCF, P-CSCF, MRFC, MGFC, BGCF, AS CCF Trả lời tính cước ACA được sử dụng để xác nhận ACR và báo cáo kết quả ACA CCF S-CSCF, I-CSCF, P-CSCF, MRFC, MGCF, BGCF, AS Điểm tham chiếu Bi
CCF dùng Bi để truyền các CDR đến hệ thống tính lập hóa đơn. Giao diện này dùng giao thức FTP trên nền TCP/IP do vậy có thể truyền các CDR khác nhau qua Bi. Các loại CDR: S-CSCF—CDR, I-CSCF—CDR, P-CSCF—CDR, BGCF—CDR, MGCF— CDR, MRFC—CDR, AS—CDR.
2.2.1.3.2 Cấu trúc tính cước online
S-CSCF, AS và MRFC là các thực thể thực hiện việc tính cước online. AS và MRFC dùng điểm tham chiếu Ro, S-CSCF dùng điểm tham chiếu ISC (IMS Server Control)
Luận văn thạc sĩ kỹ thuật 62
Hình 2-19: Hệ thống tính cước online trong IMS. Event Charging Function
Khi UE yêu cầu gì từ AS hay MRFC, AS hay MRFC liên lạc với ECF qua giao diện Ro trước khi cấp phát dịch vụ cho UE (AS hoặc MRFC nhận được địa chỉ của ECF từ
S-CSCF cấp tại mào đầu P-Charging-Function-Address). Ở IMS Release 5 thì AS hoặc MRFC liên lạc với ECF bằng ACR và ACA, còn Release 6 thì AS hoặc MRFC liên lạc với ECF bằng CCR (Credit Control Request) và CCA (Credit Control Answer) ECF hỗ trợ hai chế độ trao quyền khác nhau: tính cước sự kiện ngay lập tức và tính cước sự kiện dành riêng.
Ở chế độ tính cước sự kiện ngay lập tức (IEC – Immediate Event Charging), ECF dùng Rating Function để tìm bảng giá phù hợp cho sự kiện. Sau khi tìm được bảng giá và tính giá, ECF sẽ trừđi một lượng tiền trong tài khoản của User và cấp cho AS hoặc MRFC các ACRs tương ứng.
Ở chếđộ tính cước sự kiện với đơn vị rành riêng (ECUR – Event Charging with Unit Reservation), ECF dùng Rating Function để xác định giá của dịch vụ muốn dùng theo thông tin dịch vụ. Sau đó ECF dự trữ một lượng tiền trong tài khoản của User và trả lại UE lượng tài nguyên tương ứng ở AS hoặc MRFC. Nếu User dùng tài nguyên đó thì AS hoặc MRFC sẽ chỉ cho ECF biết lượng tài nguyên đã được dùng, ECF sẽ trừ đi lượng tiền tương ứng trong tài khoản của User. Chế độ này phù hợp khi AS hoặc MRFC không thể xác định trước được dịch vụ có thểđược cấp phát hoặc khi lượng tài nguyên đã yêu cầu chưa được user biết đến (ví dụ như thời gian hội nghi).
Session Charging Function
SCF thực hiện tính cước theo sự sử dụng tài nguyên phiên, dựa trên các yêu cầu đã nhận được từ S-CSCF qua điểm tham chiếu ISC. SCF có thể điều khiển sự thiết lập phiên bằng cách cho phép hoặc từ chối yêu cầu thiết lập phiến sau khi kiểm tra tài
Luận văn thạc sĩ kỹ thuật 63
khoản của User. SCF có thể kết thúc phiên đang tồn tại khi tài khoản của User đã cạn. SCF hỗ trợ chếđộ tính cước sự kiện với đơn vị dự trữ.
Kênh mang Charging Function
SGSN dùng điểm tham chiếu liên quan tới CAMEL AP (CAP) cho việc yêu cầu sự
chấp thuận cho dùng kênh mang từ BCF. BCF điều khiển cách dùng kênh mang.
Rating Function thực hiện xác định đơn vị, giá cả và bảng giá. Xác định đơn vị tức là thực hiện tính toán số lượng các đơn vị không liên quan tới tiền ở trong phiên (ví dụ,
đơn vị dịch vụ, thời gian) dựa vào dịch vụđã yêu cầu.
Correlation Function
Nếu một nhà khai thác muốn so sánh thông tin thu được từ các tài nguyên khác nhau (ECF, SCF và BCF), nó cần chắc chắn rằng các nhận dạng tính cước duy nhất được phân công đến mỗi sự kiện có khả năng tính cước.
Điểm tham chiếu Ro
AS và MRFC dùng các bản tin ACR và ACA của giao thức DIAMETER cho việc gửi thông tin tài khoản online qua điểm tham chiếu Ro đến ECF. Khi AS hoặc MRFC áp dụng chếđộ tính cước sự kiện trực tiếp, một ACR event được dùng để ghi thông tin tài khoản tới ECF; Ở chế độ thư hai, ACR Start, Interim và Stop được dùng cho dữ liệu tài khoản liên quan tới các phiên SIP không thành công.
Bảng 2-5: Bảng tham chiếu các bản tin tính cước online
Tên Lệnh Mục đích Viết tắt Nguồn Đích
Accounting - Request ACR được sử dụng để
thông báo hoặc ngừng thông tin tính cước tới
CCF
ACR MRFC, AS ECF
Accounting - Answer ACA được sử dụng để
xác nhận ACR và thông báo kết quả
Luận văn thạc sĩ kỹ thuật 64