Đề tài Tìm hiểu SS7 Over IP

LỜI MỞ ĐẦU Thông tin liên lạc là nhu cầu thiết yếu trong cuộc sống, đặc biệt là trong một xã hội hiện đại. Vì vậy ngành Bưu Chính Viễn Thông được xem là một ngành hết sức quan trọng cho một nền kinh tế phát triển. Trong xu hướng hoà nhập với thế giới, ngành Bưu Chính Viễn Thông cũng đã và đang phát triển, mở rộng phạm vi và năng lực hoạt động để đáp ứng đầy đủ, kịp thời của nền kinh tế trong nước. Do đó, việc nghiên cứu, đào tạo, đầu tư ứng dụng công nghệ kỹ thuật mới cho việc phát triển hệ thống thông tin liên lạc được đặc biệt chú trọng và đã có những hoạch định lâu dài cho công tác này. Trong mạng viễn thông, báo hiệu được xem là hệ thống thần kinh trung ương của một cơ thể mạng, sự phát triển của mạng viễn thông luôn song hành với sự phát triển của hệ thống báo hiệu. Do vậy phải có sự đầu tư tìm hiểu và ứng dụng các giao thức báo hiệu mới cần thiết cho sự phát triển mạng dựa trên nền tảng sẵn có. Không ngoài mục đích này, đề tài được sử dụng để tìm hiểu về báo hiệu SS7, vốn là giao thức báo hiệu liên đài chính của mạng PSTN hiện nay, đồng thời tìm hiểu thêm về các giao thức báo hiệu trong mạng thế hệ sau NGN đang được triển khai tại Việt Nam, đặc biệt là giao thức Sigtran (SS7oIP) dùng để liên kết báo hiệu giữa mạng PSTN với mạng NGN. Mong rằng đề tài sẽ đem lại kiến thức bổ ích cho những ai muốn tìm hiểu về hệ thống báo hiệu nói chung và sự liên kết báo hiệu giữa PSTN và NGN nói riêng. MỤC LỤC LỜI MỞ ĐẦU MỤC LỤCI MỤC LỤC CÁC HÌNHIV MỤC LỤC CÁC BẢNG . VI THUẬT NGỮ VIẾT TẮT VII CHƯƠNG I: TỔNG QUAN VỀ HỆ THỐNG BÁO HIỆU TRUYỀN THỐNG . 1 1.1. ĐỊNH NGHĨA VỀ BÁO HIỆU1 1.2. CHỨC NĂNG CỦA HỆ THỐNG BÁO HIỆU1 1.3. CÁC YÊU CẦU CỦA HỆ THỐNG BÁO HIỆU1 1.4. CÁC LOẠI BÁO HIỆU2 1.5. BÁO HIỆU KÊNH RIÊNG CAS. 3 1.6. BÁO HIỆU KÊNH CHUNG CCS . 3 CHƯƠNG II: HỆ THỐNG BÁO HIỆU KÊNH CHUNG SỐ 7 . 5 2.1. KIẾN TRÚC MẠNG SS7. 5 2.1.1. ĐIỂM BÁO HIỆU SP. 5 2.1.2. KÊNH BÁO HIỆU VÀ CHÙM KÊNH BÁO HIỆU6 2.1.3. CÁC PHƯƠNG THỨC BÁO HIỆU7 2.1.4. PHÂN CẤP MẠNG SS7. 8 2.2. MÔ HÌNH PHÂN LỚP CỦA SS7. 8 2.2.1. SO SÁNH VỚI MÔ HÌNH OSI. 8 2.2.2. CÁC LỚP CỦA SS7. 9 2.2.3. MTP LỚP 1. 10 2.2.4. MTP LỚP 2. 11 2.2.4.a. CÁC KHUÔN DẠNG CƠ BẢN CỦA ĐƠN VỊ BÁO HIỆU11 2.2.4.b. CÁC CHỨC NĂNG CỦA LỚP 2. 14 2.2.5. MTP LỚP 3. 17 2.2.5.a. CHỨC NĂNG XỬ LÝ BẢN TIN BÁO HIỆU17 2.2.5.b. CHỨC NĂNG QUẢN LÝ MẠNG BÁO HIỆU19 2.2.6. LỚP 4. 22 2.3. SỰ HÌNH THÀNH VÀ CHUYỂN GIAO BẢN TIN23 2.3.1. CẤU TRÚC MẠNG ISDN23 2.3.2. MÔ HÌNH CÁC LỚP TRONG MẠNG24 2.3.3. HÌNH THÀNH VÀ TRUYỀN TIN BÁO25 2.4. MỘT SỐ GIAO THỨC LỚP 4. 27 2.4.1. TUP. 27 2.4.1.a. MỘT VÀI NHÓM BẢN TIN ĐẶC BIỆT27 2.4.1.b. VÍ DỤ VỀ THỦ TỤC THIẾT LẬP, GIẢI TOẢ CUỘC GỌI. 28 2.4.2. ISUP. 29 2.4.2.a. ĐỊNH DẠNG BẢN TIN30 2.4.2.b. VÍ DỤ VỀ HOẠT ĐỘNG CỤ THỂ CỦA CÁC BẢN TIN 31 CHƯƠNG III: BÁO HIỆU TRONG NGN 33 3.1.GIỚI THIỆU VỀ NGN33 3.2. CÁC GIAO THỨC BÁO HIỆU TRONG NGN35 3.2.1. H.323. 35 3.2.1.a. TỔNG QUAN35 3.2.1.b. CẤU TRÚC CỦA H.323. 35 3.2.1.c. CHỒNG GIAO THỨC H.323. 37 3.2.1.d. HOẠT ĐỘNG CỦA H.323. 38 3.2.1.e. MỘT SỐ HOẠT ĐỘNG ĐIỂN HÌNH CỦA H.323. 39 3.2.1.f. MỘT SỐ BẢN TIN RAS H.225. 43 3.2.1.g. MỘT SỐ BẢN TIN BÁO HIỆU H.225. 43 3.2.1.h. MỘT SỐ BẢN TIN ĐIỀU KHIỂN CUỘC GỌI H.245. 44 3.2.2. MEGACO44 3.2.2.a. CẤU TRÚC CỦA MEGACO44 3.2.2.b. CONTEXT45 3.2.2.c. TEMINATION46 3.2.2.d. MỘT SỐ LỆNH MEGACO46 3.2.2.e. HOẠT ĐỘNG CỦA MEGACO47 3.2.3. SIP. 50 3.2.3.a. TỔNG QUAN50 3.2.3.b. CẤU TRÚC CỦA SIP. 51 3.2.3.c TỔNG QUAN VỀ HOẠT ĐỘNG CỦA SIP. 51 3.2.3.d. CÁC BẢN TIN SIP. 53 3.2.3.e. CÁC HOẠT ĐỘNG CHÍNH CỦA SIP. 56 3.2.3.f. LIÊN MẠNG GIỮA SIP VÀ SS7:58 3.2.4. SIGTRAN 62 CHƯƠNG IV: GIAO THỨC SIGTRAN (SS7 over IP) . 63 4.1. TỔNG QUAN VỀ SIGTRAN63 4.1.1. GIỚI THIỆU CHUNG VỀ SIGTRAN63 4.1.2. SỰ CẦN THIẾT CỦA SCTP VÀ CÁC LỚP THÍCH ỨNG63 4.1.3. KIẾN TRÚC CỦA SIGTRAN66 4.2. CÁC LỚP CỦA SIGTRAN67 4.2.1. GIAO THỨC TRUYỀN ĐIỀU KHIỂN LUỒNG (SCTP)67 4.2.1.a. CÁC CHỨC NĂNG CỦA SCTP. 67 4.2.1.b. CẤU TRÚC GÓI SCTP. 69 4.2.1.c CẤU TRÚC CHUNK70 4.2.1.d MỘT SỐ LOẠI CHUNK72 4.2.1.e. MỘT SỐ HOẠT ĐỘNG CỦA SCTP. 80 4.2.1.f. BIỂU ĐÒ TRẠNG THÁI CỦA SCTP. 84 4.2.2. CÁC LỚP THÍCH ỨNG NGƯỜI DÙNG (xUA)86 4.2.2.a. CẤU TRÚC CHUNG CỦA BẢN TIN xUA86 4.2.2.b. LỚP THÍCH ỨNG M2PA87 4.2.2.c. LỚP THÍCH ỨNG M2UA88 4.2.2.d. LỚP THÍCH ỨNG M3UA90 4.2.2.e. LỚP THÍCH ỨNG SUA92 4.2.2.f. LỚP THÍCH ỨNG IUA93 4.2.3. GIAO DIỆN KẾT NỐI SCTP VÀ LỚP TRÊN94 4.2.3.a. ULP → SCTP. 94 4.2.3.b. SCTP → ULP . 97 KẾT LUẬNA PHỤ LỤC B I. MÃ TIÊU ĐỀ CỦA BẢN TIN TUP. B II. CÁC LOẠI BẢN TIN TUP. C III. CÁC LOẠI BẢN TIN ISUP:E IV. Ý NGHĨA CÁC BẢN TIN ISUP. F V. CÁC THAM SỐ CỦA ISUP. H VI. BẢN TIN CỦA CÁC LỚP THÍCH ỨNG (xUA)J M3UAJ SUAK M2UAL TÀI LIỆU KHAM KHẢOM

doc121 trang | Chia sẻ: lvcdongnoi | Lượt xem: 3915 | Lượt tải: 1download
Bạn đang xem trước 20 trang tài liệu Đề tài Tìm hiểu SS7 Over IP, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
SHUTDOWN COMPLETE Chunk này được dùng để hoàn thành thủ tục kết thúc “mềm”. Nó không có tham số, ý nghĩa của bit T giống với chunk ABORT. Bit T bằng 0 nếu thẻ xác nhận của gói SCTP bình thường tức là bằng với thẻ khởi tạo nó nhận được khi khởi tạo kết nối (trong Chunk INIT hoặc INIT ACK mà nó nhận được). Bit T được đặt bằng 1 nếu thẻ xác nhận của nó bằng giá trị thẻ khởi tạo nó đã gửi đi khi khởi tạo kết nối (Trong Chunk INIT và Chunk INIT ACK mà nó gửi đi). 4.2.1.e. MỘT SỐ HOẠT ĐỘNG CỦA SCTP Thủ tục khởi tạo kết nối: Kết nối SCTP được khởi tạo theo cơ chế bắt tay 4 bước. Lấy một ví dụ về thiết lập kết nối giữa 2 đầu cuối mạng trong đó đầu cuối A khởi tạo và đầu cuối Z chấp nhận kết nối. Bước 1: A gửi chunk INIT tới Z, nó đặt một giá trị ngẫu nhiên trong thẻ Khởi tạo có giá trị từ 1 đến 232 – 1 (Tag_A), đồng thời A khởi động bộ đếm thời gian T1 và chuyển sang trạng thái “Chờ Cookie” (COOKIE-WAIT). Bước 2: Sau khi Z nhận được chunk INIT, nó sẽ gửi lại chunk INIT ACK theo địa chỉ IP nguồn trong gói IP của INIT. Thẻ xác nhận của gói SCTP chứa chunk INIT ACK sẽ được đặt bằng Tag_A, thẻ khởi tạo trong chunk INIT ACK được gán một giá trị ngẫu nhiên từ 1 đến 232 – 1 (Tag_Z). Ngoài ra, Z cũng tạo một khối điều khiển truyền (TCB: Transmission Control Block) có chứa các dữ liệu liên quan tới kết nối, đồng thời dùng hàm băm và khóa bí mật để tạo một mã nhận thực bản tin (MAC: Message Authentication Code) từ TCB. Kết hợp TCB và MAC tạo thành Cookie và gửi theo chunk INIT ACK. Bước 3: Sau khi nhận INIT ACK từ Z, A sẽ gửi Cookie ngược lại cho Z trong chunk COOKIE ECHO. Đồng thời A khởi động lại bộ đếm T1 và chuyển sang trạng thái “Đã phản hồi Cookie” (COOKIE-ECHOED). Trong gói SCTP chứa Chunk COOKIE ECHO có thể gắn kèm các chunk DATA nhưng phải ở phía sau chunk COOKIE ECHO. Bước 4: Khi Z nhận được chunk COOKIE ECHO nó sẽ kiểm tra TCB và MAC nếu đúng Z sẽ xác nhận bằng cách gửi lại cho A chunk COOKIE ACK đồng thời chuẩn bị tài nguyên cho kết nối. Khi A nhận được thông báo này nó sẽ ngừng T1 và chuyển sang trạng thái “Đã kết nối” (ESTABLISHED) quá trình bắt tay hoàn tất, kết nối có thể hoạt động. Hình 4.22: Thủ tục khởi tạo kết nối SCTP Cơ chế chuyển giao dữ liệu Cần nhắc lại rằng SCTP cho phép tạo nhiều luồng độc lập bên trong 1 kết nối SCTP, nhờ vậy mà nó tránh được hiện tượng nghẽn đầu dòng giữa các luồng bản tin độc lập. Ngoài ra SCTP còn cung cấp 1 cơ chế cho phép bỏ qua thứ tự chuyển giao, bản tin được chuyển lên cho user của SCTP ngay khi nó hoàn tất việc nhận (chuyển giao theo thứ tự đến). SCTP có 2 mức độ hoạt động: Mức thứ nhất bảo đảm truyền tin cậy dựa vào các thẻ xác thực và trường checksum, số tuần tự TSN và cơ chế truyền lại có lựa chọn. Sau khi qua mức thứ nhất, các bản tin sẽ được đưa lên mức thứ 2. Mức này nhận biết các luồng độc lập trong kết nối và nó có nhiệm vụ chuyển bản tin lên lên cho user tương ứng theo luồng. Khi kết nối được thiết lập, số luồng trong đó được thỏa thuận giữa 2 đầu cuối. Trong mỗi luồng, SCTP sẽ gán số tuần tự luồng (SSN: Stream Sequence Number) cho các bản tin. Tại đầu cuối, mức 2 SCTP sẽ nhận diện luồng thông qua trường “Số nhận dạng luồng” (Stream ID). Việc chuyển gói lên cho các User lớp trên theo 2 phương thức. Nếu gói được đánh dấu cho phép bỏ qua thứ tự truyền thì nó sẽ được đưa thẳng lên cho User (Thông thường đây là các bản tin độc lập, quan trọng, ví dụ như bản tin hủy bỏ giao dịch của một ứng dụng). Còn thông thường thì các bản tin phải được chuyển lên theo đúng số tuần tự luồng. Hình 4.23: Cơ chế chuyển giao bản tin SCTP dùng cơ chế truyền lại theo thời gian. Sau một khoảng thời gian theo quy định, bên nhận sẽ gửi lại bản tin “Xác nhận có lựa chọn” (SACK) để thông báo về các gói đã nhận tốt và các gói bị trùng lặp. Một gói sau khi phát vẫn được giữ trong bộ đệm, chỉ khi gói được xác nhận nó mới được xóa khỏi hàng đợi. Sau thời gian quy định, các gói chưa được xác nhận sẽ được truyền lại. SCTP dùng cửa sổ trượt trong cơ chế điều khiển luồng. Đầu thu có thể thay đổi tốc độ của đầu phát bằng cách gửi thông báo về kích thước cửa sổ thu đính trong bản tin SACK. Chức năng điều khiển luồng phải luôn theo dõi việc truyền – xác nhận – truyền lại của kết nối để liên tục cập nhật trạng thái kết nối và lựa chọn các tham số thích hợp cho việc điều khiển luồng và tránh nghẽn. Khi cần thiết việc truyền lại hoặc toàn bộ việc truyền được thay đổi sang một đường truyền khác trên cùng kết nối đó là nhờ SCTP hỗ trợ cơ chế đa địa chỉ. Cơ chế đa địa chỉ (Multi-homing) Multi-homing là phương pháp hữu hiệu chống lại việc lỗi mạng về mặt vật lý, tạo sự an toàn cho kết nối. Nó cho phép một đầu cuối được kết nối vào mạng IP bằng nhiều giao diện vật lý độc lập, mỗi giao diện sử dụng địa chỉ IP riêng. Khi một giao diện bị lỗi, kết nối được duy trì bằng cách chuyển sang một giao diện khác mà không cần phải thiết lập lại. * Quản lý địa chỉ: Nếu một đầu cuối là multi-homed, khi muốn khởi tạo kết nối nó sẽ thông báo tất cả các địa chỉ của mình cho phía đối tác trong bản tin khởi tạo (INIT). Bản tin này chỉ cần gửi tới một địa chỉ của đối tác mà nó biết, nếu phía đối tác cũng là multi-homed nó sẽ gửi về danh sách các địa chỉ IP trong bản tin INIT ACK. Nếu không có danh sách địa chỉ trong bản tin INIT hay INIT-ACK thì địa chỉ IP nguồn trong gói IP có chứa bản tin SCTP sẽ được sử dụng. SCTP hỗ trợ đồng thời cả IPv4 và IPv6, mỗi sự kết hợp địa chỉ nguồn - đích sẽ được coi là một đường truyền (Transmission path) tương đương nhau và nó sẽ chọn 1 đường làm đường truyền mặc định. Một đường khác có thể được sử dụng cho việc truyền lại. Các User của SCTP sẽ theo dõi trạng thái của đường truyền và khi cần nó sẽ yêu cầu SCTP thay đổi một đường truyền khác. Lưu ý là khi chọn một đường truyền khác thì dù địa chỉ IP thay đổi nhưng số port SCTP vẫn được giữ nguyên. Như vậy mỗi đầu cuối SCTP được đặc trưng bởi một danh sách các địa chỉ IP và một port SCTP, mỗi kết nối SCTP được đặc trưng bởi 2 tập hợp địa chỉ IP và 2 port tương ứng cho 2 đầu cuối. Khả năng Fragmentation và Bunlding: một ưu điểm nữa của SCTP là nó hỗ trợ gom và phân mảnh bản tin. Một gói SCTP có thể bao gồm nhiều bản tin và một bản tin cũng có thể được chia nhỏ và truyền trên nhiều gói, khả năng này giúp gói SCTP chọn kích thước phù hợp để thích ứng tốt hơn với nghẽn và tỉ lệ lỗi trên đường truyền. Thủ tục kết thúc kết nối Mỗi đầu cuối đều có thể yêu cầu kết thúc kết nối, có 2 hình thức là kết thúc “cứng” (hủy bỏ) và kết thúc “mềm”. Kết thúc cứng được định nghĩa là ngay khi gửi yêu cầu hủy bỏ hay nhận được yêu cầu hủy bỏ, tất cả dữ liệu trong bộ đệm gửi của 2 bên đều được xóa bỏ và không được truyền tới đối tác. Kết thúc mềm là ngay khi nhận yêu cầu kết thúc, SCTP sẽ không nhận dữ liệu từ User chuyển xuống nhưng vẫn tiếp tục trao đổi dữ liệu cho đến khi hết hàng đợi truyền của 2 bên. Kết thúc cứng: Khi một đầu cuối muốn kết thúc một kết nối đang tồn tại nó sẽ gửi chunk ABORT cho đối tác. Trong gói có chứa Chunk ABORT sẽ chỉ có 1 số loại Chunk điều khiển được phép đi kèm và phải đặt trước Chunk ABORT, chunk DATA không được gắn cùng trong một gói với chunk ABORT. Nếu kết nối bị hủy bỏ theo yêu cầu của lớp trên thì nguyên nhân lỗi có thể được thông báo trong chunk ABORT bằng thông báo lỗi 12 (Hủy bỏ bởi User). Đầu cuối nhận được gói có chứa Chunk ABORT sẽ không gửi đi thêm một gói nào. Sau khi kiểm tra thẻ xác nhận nó sẽ xóa kết nối trong bản ghi của nó và thông báo cho lớp trên của nó. Nguyên nhân “Hủy bỏ bởi User” nếu có cũng sẽ được đưa lên lớp trên. Kết thúc mềm: Gọi A là bên yêu cầu kết thúc và Z là bên chấp nhận yêu cầu, thủ tục kết thúc mềm diễn ra theo 3 bước như sau. Bước 1: Kết thúc mềm được thực hiện theo yêu cầu của User. Khi nhận được yêu cầu kết thúc của lớp trên, SCTP A sẽ chuyển sang trạng thái “Chờ kết thúc” (SHUTDOWN PENDING) và chờ cho tất cả các dữ liệu trong hàng đợi phát được xóa hết (tức là đã truyền đi và được đối tác Z xác nhận bằng bản tin SACK). Trong lúc chờ nó sẽ không chấp nhận yêu cầu truyền dữ liệu mới từ lớp trên. Khi hàng đợi phát đã trống, A sẽ gửi chunk SHUTDOWN cho Z bao gồm luôn số “Xác nhận TSN tích lũy”. Đồng thời nó bắt đầu bộ đếm thời gian T và chuyển sang trạng thái “Đã gửi yêu cầu kết thúc” (SHUTDOWN-SENT). Sau thời gian T hoặc ngay khi A nhận được một chunk DATA nó sẽ khởi động lại bộ đếm, gửi lại chunk SHUTDOWN và cập nhật số “Xác nhận TSN tích lũy”. Lưu ý là nếu tồn tại GAB hay TSN bị trùng, nó sẽ phải gắn kèm chunk SACK với chunk SHUTDOWN trong cùng một gói SCTP. Số lần gửi chunk SHUTDOWN liên tiếp mà không nhận được thêm TSN nào có thể được giới hạn bởi User, nếu vượt quá giới hạn này đầu cuối có thể thông báo cho User, xóa TCB và đóng kết nối (tức là xóa các bản ghi về kết nối). Bước 2: Khi Z nhận được chunk SHUTDOWN nó sẽ chuyển sang trạng thái “Đã nhận yêu cầu kết thúc” (SHUTDOWN – RECEIVED), ngừng nhận yêu cầu truyền dữ liệu từ lớp trên và tiếp tục truyền dữ liệu với đối tác đến khi hàng đợi phát rỗng. Đến khi không còn dữ liệu trong hàng đợi phát Z sẽ gửi SHUTDOWN ACK đến cho A, khởi động bộ đếm T và chuyển sang trạng thái “Đã gửi xác nhận kết thúc” (SHUTDOWN-ACK-SENT). Quá thời gian T nó sẽ gửi tiếp chunk SHUTDOWN ACK. User có thể giới hạn số lần gửi SHUTDOWN ACK, nếu số lần gửi đạt mức thì đầu cuối sẽ thông báo với User, xóa TCB và đóng kết nối. Khi nhận được chunk SHUTDOWN ACK, A sẽ ngừng bộ đếm và gửi trả về chunk SHUTDOWN COMPLETE cho Z rồi xóa toàn bộ bản ghi về kết nối. Bước 3: Khi nhận được chunk SHUTDOWN COMPLETE, Z sẽ ngừng bộ đếm và xóa toàn bộ bản ghi về kết nối. Quá trình kết thúc “mềm” hoàn tất. Hình 4.24: Thủ tục kết thúc mềm kết nối SCTP 4.2.1.f. SƠ ĐỒ TRẠNG THÁI CỦA SCTP Hình 4.25 biểu diễn sơ đồ các trạng thái của SCTP với các lệnh nhận được từ các User của SCTP được biểu diễn trong [] (ví dụ: [SHUTDOWN]) còn các chunk được in hoa, ví dụ SHUTDOWN. Hình 4.25: Sơ đồ các trạng thái của SCTP 4.2.2. CÁC LỚP THÍCH ỨNG NGƯỜI DÙNG (xUA) 4.2.2.a. CẤU TRÚC CHUNG CỦA BẢN TIN xUA Cấu trúc chung của các bản tin lớp thích ứng người dùng như sau: Hình 4.26: Cấu trúc chung của bản tin các lớp thích ứng xUA Trong đó: - Phiên bản hiện tại của các lớp thích ứng được định nghĩa bởi IETF là 1.0. - 8 bit dự phòng được đặt bằng 0 và được bỏ qua tại đầu thu. - Lớp bản tin (Message Class): gồm 8 bit, ý nghĩa của nó được quy định như sau: Giá trị Ý nghĩa lớp bản tin 0 Các bản tin quản lý [IUA/M2UA/M3UA/SUA] 1 Các bản tin thích ứng người dùng MTP3 [M3UA] 2 Các bản tin quản lý mạng báo hiệu SS7 [M3UA/SUA] 3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA] 4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA] 5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages [IUA] 6 Các bản tin thích ứng người dùng MTP2 [M2UA] 7 Các bản tin không kết nối [SUA] 8 Các bản tin hướng kết nối [SUA] 9 Các bản tin quản lý khóa định tuyến Routing Key Management (RKM) Messages (M3UA) 10 Các bản tin quản lý nhận diện giao diện Interface Identifier Management (IIM) Messages (M2UA) 11 - 127 Dành riêng cho IETF 128 - 255 Dành riêng cho IETF – định nghĩa các lớp bản tin mở rộng Bảng 4.6: Các lớp bản tin thích ứng xUA - Mỗi loại lớp thích ứng có một số các lớp bản tin thích hợp. Tương ứng với mỗi lớp sẽ có một số loại bản tin phục vụ cho yêu cầu của nó. - Trường độ dài bản tin gồm 32 bit, nó cho biết kích thước của bản tin (theo đơn vị byte) tính luôn các byte chèn. Ở đầu cuối sẽ chấp nhận bản tin dù trường này có tính thêm các byte chèn của tham số cuối cùng hay không. - Mỗi bản tin thích ứng người dùng sẽ gồm phần mào đầu chung (bao gồm các trường Phiên bản, Dự phòng, Lớp bản tin, Loại bản tin và trường Độ dài bản tin) cộng với các thông tin đặc trưng của mỗi loại bản tin (Header riêng, các biến và tham số riêng). Cấu trúc chung của một tham số như sau. Hình 4.27: Cấu trúc chung của một tham số trong bản tin xUA + Thẻ tham số cho biết loại tham số được sử dụng. + Độ dài tham số cho biết kích thước của tham số tính theo byte. Độ dài này không bao gồm phần byte chèn ở cuối tham số. + Giá trị tham số: loại giá trị ở đây tùy thuộc vào loại tham số được sử dụng. 4.2.2.b. LỚP THÍCH ỨNG M2PA M2PA là giao thức truyền các bản tin báo hiệu lớp MTP3 qua mạng IP sử dụng giao thức truyền dẫn SCTP. M2PA tương đương với M2UA. Tuy nhiên, nó không chỉ là cung cấp kết nối giữa 2 lớp MTP2 và MTP3 cách xa nhau mà nó có thể thay thế hoàn toàn lớp MTP2 bên dưới lớp MTP3. Người dùng của M2PA là lớp MTP3 ở cả 2 đầu kết nối (với M2UA, người dùng một đầu là MTP3, đầu còn lại là SG NIF). Hình 4.28: Mô hình kiến trúc của M2PA M2PA cho phép các lớp MTP3 ngang hàng của các SG có thể liên lạc trực tiếp với nhau. Thực chất, nó mở rộng mạng SS7 sang mạng IP. Mô hình này được áp dụng chủ yếu cho các kết nối giữa SG với SG, sử dụng như cầu nối giữa 2 mạng SS7, trong trường hợp này mỗi SG có thể kết nối tới nhiều SG khác mà không cần phải quan tâm tới lớp trên mà nó phải hỗ trợ vì đã có lớp MTP3 rồi. Lớp MTP3 tại mỗi SG sẽ cung cấp chức năng định tuyến và quản lý các link MTP2/M2PA. Vì có lớp MTP3 cho nên mỗi SG phải có một mã điểm báo hiệu tương ứng. M2PA cũng có thể thay thế link MTP2 trong trường hợp kết nối giữa SG với IP SCP bên phía mạng IP. Điểm khác biệt giữa M2PA và M2UA chính là M2PA tự nó có khả năng cung cấp các dịch vụ của lớp MTP2 còn M2UA thì cung cấp dịch vụ bằng cách tạo một giao diện ảo để sử dụng các dịch vụ của MTP2 ở xa. M2PA có các chức năng sau: Duy trì hoạt động liên tục giữa các thực thể ngang hàng MTP3 giao tiếp với nhau qua mạng IP. Thực hiện kích hoạt và ngưng các liên kết theo yêu cầu của MTP3. Điều hành các thông tin trạng thái liên kết, quản lý việc truyền tuần tự và bộ đệm truyền lại. Bản tin của M2PA có dạng như sau: Hình 4.29: Cấu trúc bản tin M2PA - M2PA chỉ có 1 lớp bản tin là lớp 11. Với Loại bản tin bằng 1, đây là bản tin chứa dữ liệu User, nếu loại bản tin bằng 2, đây là bản tin chứa trạng thái liên kết. - Phần Header riêng của bản tin chứa số tuần tự hướng đi và số tuần tự hướng về. Để có thêm thông tin về các lớp và loại bản tin của M2PA, có thể kham khảo phần phụ lục và RFC 4165. 4.2.2.c. LỚP THÍCH ỨNG M2UA M2UA được sử dụng như đường trục truyền các bản tin báo hiệu lớp người sử dụng MTP2 (ví dụ như MTP3) qua mạng IP sử dụng giao thức SCTP. M2UA cung cấp các dịch vụ cho lớp người sử dụng của nó tương tự như các dịch vụ do MTP2 cung cấp cho MTP3. M2UA thường được dùng trong kết nối giữa SG và SGC, khi đó SG nhận bản tin báo hiệu SS7 từ giao diện mạng SS7 tiêu chuẩn và chuyển đến cho SGC. Đứng từ phía mạng SS7 sẽ thấy SG đóng vai trò của một kết cuối liên kết báo hiệu. Hình 4.30: Liên kết hoạt động SS7 – IP sử dụng M2UA Trong mô hình trên ta thấy MTP3 ở MGC là User của lớp MTP2 ở SG, nhưng cả 2 đều không nhận ra được chúng đang hoạt động trên 2 thiết bị riêng rẽ. M2UA được sử dụng cho các mục đích sau: - Cung cấp một cơ chế cho phép truyền bản tin báo hiệu User của MTP2 qua mạng IP sử dụng giao thức SCTP. - Tập trung lưu lượng SS7 từ các link SS7 cách xa nhau về một điểm tập trung trên mạng. - Bằng việc sử dụng M2UA, một vài điểm báo hiệu có thể hợp nhất thành một điểm báo hiệu tập trung. Ta biết là mỗi điểm báo hiệu có lớp MTP3 phải có một mã điểm báo hiệu nhất định. Trong trường hợp này, nếu mỗi SG sử dụng lớp MTP3 thì mỗi SG sẽ phải có một mã điểm báo hiệu riêng đối với mạng SS7. Điều này sẽ dẫn đến sự lãng phí địa chỉ SS7. Bằng việc sử dụng lớp M2UA, sẽ chỉ cần cấp phát một mã điểm báo hiệu cho MGC còn các SG thì không cần. Khi đó các bản tin lớp MTP2 mà SG nhận được sẽ được chuyển đến lớp MTP3 ở MGC để xử lý và định tuyến tới phía đích. Đứng từ phía mỗi mạng SS7 mà các SG kết nối tới sẽ thấy các liên kết nối tới SG là các liên kết của một MGC. Hình 4.31: Tính trong suốt của SG đối với lớp mạng SS7 khi sử dụng M2UA. Để có thêm thông tin về các lớp và loại bản tin của M2UA, có thể kham khảo phần phụ lục và RFC 3331. 4.2.2.d. LỚP THÍCH ỨNG M3UA M3UA là giao thức hỗ trợ cho việc truyền dẫn các bản tin báo hiệu của MTP3-User (ví dụ như ISUP, SCCP) qua mạng IP sử dụng giao thức SCTP. M3UA tương tự như M2UA về cả chức năng và cách thức hoạt động. Giao thức này cũng hoạt động theo mô hình Chủ - tớ, nó thường được sử dụng ở giao tiếp giữa SG và MGC hay các IP SCP bên phía mạng IP. SG có giao diện kết nối tới mạng SS7, nó nhận các báo hiệu SS7 ở trên lớp MTP3 ví dụ như ISUP, SCCP và các MTP3-User khác rồi chuyển tới MGC thông qua các kết nối SCTP. M3UA giúp cung cấp dịch vụ lớp MTP3 cho User SS7 của MGC, do vậy nó mở rộng mạng báo hiệu SS7 sang phía mạng IP. Hình 4.32: Mô hình kiến trúc M3UA Trong trường hợp này, MTP3 tại SG sẽ không nhận biết được là lớp người dùng ISUP của MGC đặt ở xa. Tương tự, lớp ISUP bên phía MGC cũng không biết được là nó đang được phục vụ bởi lớp MTP3 của SG cục bộ. Do vậy các bản tin báo hiệu số 7 sẽ được truyền một cách trong suốt từ SG tới MGC qua mạng IP. Trong mô hình sử dụng M3UA, MTP3 kết thúc tại SG nên định tuyến thông qua mã điểm báo hiệu SS7 được kết thúc tại SG, do đó SG sẽ được cấp phát một mã điểm báo hiệu chứ không phải là MGC, tuy nhiên để phục vụ cho việc định tuyến khi có nhiều MGC trong mạng IP, một hay một nhóm các MGC được cấp phát một mã điểm báo hiệu. Việc định tuyến tiếp trong mạng IP được thực hiện dựa vào các Khóa định tuyến (RK: Routing Key). Khóa định tuyến là 1 nhóm các tham số SS7 (Ví dụ: DPC) và giá trị của nó được ánh xạ tới một hay một nhóm địa chỉ đích trong mạng IP. Lấy ví dụ về RK trong hình, với MGC-A và MGC-B là được gom chung lại tạo thành 1 Cluster và được gán cho RK-1. Khi STP-A chuyển một bản tin ISUP với DPC 1.1.1 tới SG. SG sẽ tìm trong bảng định tuyến của nó và tìm thấy 2 giá trị phù hợp tương ứng với địa chỉ IP của MGC-A và MGC-B. Theo mặc định nó sẽ định tuyến bản tin đến MGC-A. Nếu MGC-A gặp sự cố hoặc đường truyền bị nghẽn thì SG sẽ chuyển các bản tin đến MGC-B. Hình 4.33: Định tuyến trong mạng IP bằng Routing Key Như vậy RK sẽ giúp định tuyến các bản tin SS7 trong mạng IP và kỹ thuật sử dụng cluster sẽ giúp tăng độ an toàn và chia tải giữa các MGC. Để có thêm thông tin về các lớp và loại bản tin của M3UA, có thể kham khảo phần phụ lục và RFC 4666. 4.2.2.e. LỚP THÍCH ỨNG SUA SUA là giao thức hỗ trợ truyền dẫn các bản tin của SCCP-User qua mạng IP sử dụng giao thức SCTP. Nó cho phép truy nhập tới các lớp ứng dụng (ví dụ như TCAP) tại IP SCP thông qua SG. Kiến trúc mạng sử dụng SUA cho phép một SG có thể kết nối đến nhiều IP SCP. Lớp MTP3 nằm ở SG nên SG được cấp một mã điểm báo hiệu còn các IP SCP không cần phải có lớp MTP3 cục bộ, do vậy không đòi hỏi phải có mã điểm báo hiệu riêng. Hình 4.34: Mô hình kiến trúc SUA SUA hỗ trợ các chức năng sau: - Truyền dẫn các bản tin SCCP (TCAP, MAP, INAP...). - Hỗ trợ dịch vụ không kết nối và hướng kết nối của SCCP. - Quản lý các kết nối truyền tải SCTP giữa SG và một hay nhiều nút báo hiệu phía mạng IP, bảo đảm hoạt động liên tục của các User. - Hỗ trợ các nút báo hiệu phân tán phía mạng IP. - Thông báo về các thay đổi trạng thái phục vụ cho mục đích quản lý. Để có thêm thông tin về các lớp và loại bản tin của SUA có thể kham khảo phần phụ lục và RFC 3868. 4.2.2.f. LỚP THÍCH ỨNG IUA IUA được sử dụng để mang bản tin Q.931 qua mạng IP trong liên kết giữa SG và MGC Hình 4.35: Liên kết hoạt động ISDN – IP sử dụng IUA Cũng giống như M2UA, M3UA hay SUA, nguyên tắc hoạt động của IUA là tạo ra một giao diện ảo cho phép Q931 sử dụng các dịch vụ của Q921 từ xa. IUA cung cấp các khả năng sau: - Ánh xạ: Một MGC có thể quản lý nhiều SG, một SG có thể có nhiều giao diện kết nối đến ISDN như T1, E1, và cả khe thời gian TDM. IUA sẽ gán các mã nhận dạng giao diện cho các giao diện vật lý này và dựa vào nó để quản lý trạng thái của các mã nhận dạng đầu cuối (TEI: ISDN Terminal Endpoint Identifier) và mã nhận dạng điểm truy cập dịch vụ (SAPI: Service Access Point Identifier). Lưu ý là việc gán này được thực hiện, thay đổi và xóa bỏ theo yêu cầu của các tiến trình máy chủ ứng dụng (ASP: Application Server Process). - Trạng thái của ASP: Lớp IUA trên SG duy trì trạng thái của ASP mà nó hỗ trợ. Trạng thái của ASP thay đổi bởi việc nhận các bản tin ngang hàng hay nhận các tín hiệu từ kết nối SCTP cục bộ. - Quản lý luồng SCTP: SCTP cho phép User (trong trường hợp này là IUA) xác định số luồng cần mở khi khởi tạo kết nối và lựa chọn đường truyền trong kết nối. IUA cũng ánh xạ mã nhận diện giao diện với kết nối và luồng SCTP. Thông thường mỗi luồng SCTP được dùng cho một kênh D để có độ trễ phù hợp trong quá trình lưu trong bộ đệm và truyền đi. - Quản lý sự liên tục của mạng: Ví dụ một kết nối SCTP bị hỏng, lớp IUA của SG và ASP sẽ tạo yêu cầu giải tỏa kết nối. - Quản lý nghẽn: nếu lớp IUA bị nghẽn (không xử lý kịp các bản tin SCTP đưa lên, nó sẽ ngừng đọc từ kết nối SCTP để điều khiển luồng phía phát. Để có thêm thông tin về các lớp và loại bản tin của IUA có thể kham khảo phần phụ lục và RFC 4233. 4.2.3. GIAO DIỆN KẾT NỐI SCTP VÀ LỚP TRÊN Các giao thức lớp trên (ULP: Upper Layer Protocol) (hay các User của SCTP) sẽ gửi các nguyên hàm (Primitive) xuống cho SCTP (tương tự như lời gọi hàm trong lập trình) để yêu cầu dịch vụ đồng thời nhận các thông báo từ SCTP cho các sự kiện khác nhau. Những thực thể SCTP khác nhau có thể có các giao diện ULP khác nhau nhưng tất cả các SCTP phải cung cấp bộ dịch vụ tối thiểu để bảo đảm tất cả các thực thể SCTP có thể hỗ trợ cùng một hệ phân cấp giao thức. 4.2.3.a. ULP → SCTP Để mô tả các bộ phận chức năng trong giao diện ULP -> SCTP, trong phần này sẽ trình bày các nguyên hàm tương tự theo các thủ tục gọi hàm trong các ngôn ngữ lập trình bậc cao. Định dạng chung của chúng như sau: TÊN_HÀM (tham số 1, tham số 2, [tham số 3]...) -> giá trị trả về 1, giá trị trả về 2... Trong đó: TÊN_HÀM là tên lệnh (nguyên hàm). Tham số là giá trị cần cung cấp cho SCTP khi thực hiện lệnh. Các tham số không để trong [] là các tham số bắt buộc. Các tham số để trong [] là các tham số tùy chọn có thể có hay không. Nếu thiếu các tham số tùy chọn thì SCTP sẽ sử dụng các giá trị mặc định được quy ước trước. Giá trị trả về kết quả mà SCTP trả về cho ULP. Hiện tại IETF định nghĩa 16 nguyên hàm cơ bản mà SCTP phải thực hỗ trợ là: Initialize Associate Shutdown Abort Send Set Primary Receive Status Change Heartbeat Request HeartBeat Get SRTT Report Set Failure Threshold Set Protocol Parameters Receive unsent message Receive unacknowledged message Destroy SCTP instance Initialize: Khởi tạo Định dạng: INITIALIZE ([local port],[local eligible address list]) -> local SCTP instance name Lệnh này yêu cầu SCTP khởi tạo cấu trúc dữ liệu bên trong nó và cấp phát tài nguyên cần thiết để thiết lập môi trường hoạt động. SCTP sẽ trả về cho ULP tên cục bộ của SCTP tương ứng. Local port: cổng SCTP (lớp 4) mà ULP muốn, nếu tham số này không có thì SCTP sẽ tự chọn cổng thích hợp. Local eligible address list: Các địa chỉ IP thích hợp của điểm cuối SCTP cục bộ mà ULP muốn sử dụng trong kết nối này (để áp dụng cơ chế multi-homing, hoặc để tiết kiệm tài nguyên) chúng sẽ được gửi cho phía đối tác trong bản tin INIT. Nếu tham số này không có thì SCTP sẽ sử dụng toàn bộ địa chỉ IP mà nút đó có. Associate: khởi tạo kết nối. Định dạng: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count] Lệnh này thực hiện sau lệnh Inittiate để yêu cầu SCTP khởi tạo kết nối tới địa chỉ [IP,port] = destination transport addr. outbound stream count: cho biết số luồng phát mà SCTP muốn tạo. SCTP sẽ trả về mã danh định của kết nối, danh sách địa chỉ truyền tải của đối tác và số luồng phát đã được tạo. Danh sách địa chỉ truyền tải được dùng để ULP chọn đường truyền chính cho việc phát các gói và khi cần có thể chọn đường truyền khác. Shutdown: kết thúc “mềm” kết nối. Định dạng: SHUTDOWN (association id) -> result Lệnh này yêu cầu SCTP kết thúc “mềm” kết nối có mã số là association id. Abort: Hủy bỏ kết nối. Định dạng: ABORT (association id [, Upper Layer Abort Reason]) -> result Lệnh này yêu cầu SCTP kết thúc “cứng” kết nối có mã số là association id. Tham số Upper Layer Abort Reason nếu có sẽ được gửi cho phía đối tác trong bản tin ABORT để thông báo nguyên nhân hủy bỏ kết nối. Send: Yêu cầu SCTP gửi dữ liệu của User. Định dạng: SEND (association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) -> result Tham số buffer address cho biết vị trí lưu trữ của bản tin User cần phát. Tham số byte count cho biết độ dài dữ liệu User tính theo byte. Context: là một số nguyên 32 bit. Nếu việc truyền bản tin User bị lỗi thì SCTP sẽ gửi thông báo lỗi có chứa số này về cho User. Stream ID chỉ thị lồng nào sẽ được dùng để phát dữ liệu, mặc định là 0. Life time: xác định thời gian sống của dữ liệu, nếu quá thời gian này mà dữ liệu chưa được phát thì bản tin bị hủy bỏ. Destination transport address: Mặc định gói sẽ được chuyển đi trên đường truyền chính, nếu ULP muốn nó có thể chọn một đường truyền khác cho gói. Unordered flag: nếu ULP muốn bản tin được chuyển giao không theo thứ tự luồng (ở đầu cuối sau khi bản tin được nhận tốt nó sẽ chuyển thẳng lên cho ULP đích mà không cần quan tâm đến số thứ tự trong luồng.) No-bundle flag: Yêu cầu SCTP không được gom bản tin này chung một gói với các bản tin khác. Tuy nhiên SCTP vẫn có thể thực hiện gom bản tin nếu mạng nghẽn. Payload protocol-id: giá trị nguyên 32 bit để chỉ dẫn cho ULP đối tác biết loại tải giao thức đang được truyền. Set Primary: Định dạng: SETPRIMARY (association id, destination transport address [,source transport address] ) -> result Bản tin này được dùng để chọn địa chỉ IP đích và địa chỉ IP nguồn cho đường truyền chính của một kết nối. Receive: đọc bản tin đã nhận. Định dạng: RECEIVE (association id, buffer address, buffer size [,]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] ] [,payload protocol-id] Lệnh này yêu cầu SCTP gửi lên cho ULP bản tin đầu tiên trong hàng đợi nhận của luồng stream id trong kết nối association id và đưa vào bộ đệm tại vị trí buffer address, số byte tối đa là buffer size. SCTP trả về số byte đã đọc trong biến byte count. Nếu đây là toàn bộ bản tin, hoặc phần cuối của bản tin thì partial flag được đặt bằng 0, nếu bản tin chưa đủ thì bit này được đặt bằng 0, số delivery number cho biết thứ tự của phần đó đồng thời stream id và stream sequence number cũng phải được gửi kèm. Status: Yêu cầu trạng thái Định dạng: STATUS (association id) -> status data SCTP sẽ gửi trả lại khối dữ liệu có chứa các thông tin sau: Trạng thái của kết nối. Danh sách địa chỉ đích và khả năng liên lạc tới các địa chỉ này. Kích thước cửa sổ nhận. Kích thước cửa sổ nghẽn. Số chunk DATA đã gửi nhưng chưa được xác nhận. Số chunk DATA số chunk DATA chờ xác nhận cho đối tác. Đường truyền chính. Thời gian khứ hồi (SRTT: Smoothed round trip time) trên đường truyền chính. Thời gian trễ truyền lại (RTO: Retransmission timeout). Và các SRTT, STO trên các địa chỉ đích khác. Change Heartbeat: thay đổi trạng thái Heartbeat Định dạng: CHANGE HEARTBEAT (association id, destination transport address, new state [,]) -> result Chuyển trạng thái sử dụng Heartbeat (cho phép hay không) đối với địa chỉ đích destination transport address trong kết nối association id. Nếu cho phép Heartbeat thì chu kỳ truyền lại sẽ được đặt bằng interval (ms). Request HeartBeat Định dạng: REQUESTHEARTBEAT (association id, destination transport address) -> result SCTp sẽ trả về thông báo có thành công hay không. Get SRTT Report: Lấy thông báo về SRTT Định dạng: GETSRTTREPORT (association id, destination transport address) -> srtt result Yêu cầu SCTP thông báo về kết quả đo SRTT trên đường truyền tới địa chỉ đích destination transport address của kết nối association id. Set Failure Threshold: Định dạng: SETFAILURETHRESHOLD (association id, destination transport address, failure threshold) -> result Lệnh này sẽ đặt mức ngưỡng cho Path.Max.Retrans (Ngưỡng tối đa số lần liên tiếp truyền lại hoặc gửi Heartbeat không thành công trên đường truyền) Path.Max.Retrans = failure threshold Set Protocol Parameters: Thiết lập các tham xô giao thức Định dạng: SETPROTOCOLPARAMETERS (association id, [destination transport address,] protocol parameter list) -> result Protocol parameter list: Danh sách các tham số giao thức gồm tên và giá trị mà ULP muốn thiết lập (Ví dụ: Association.Max.Retrans: ngưỡng tối đa số lần liên tiếp truyền lại hoặc gửi Heartbeat không thành công trên kết nối) Receive Unsent Message Định dạng: RECEIVE_UNSENT (data retrieval id, buffer address, buffer size [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id]) Yêu cầu SCTP trả về bản tin chưa được gửi đi vì lý do nào đó (ví dụ như kết nối bị hủy bỏ trước khi nó có thể được gửi đi lần đầu). Tham số data retrieval id là mã nhận diện được gửi trong thông báo lỗi của SCTP gửi cho ULP. Receive Unacknowledged Message Định dạng: RECEIVE_UNACKED (data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) Yêu cầu SCTP trả về các bản tin đã được gửi nhưng chưa được xác nhận. Destroy SCTP Instance Định dạng: DESTROY (local SCTP instance name) Lệnh này yêu cầu SCTP giải phóng tài nguyên của một SCTP cục bộ. 4.2.3.b. SCTP → ULP IETF định nghĩa các thông báo sau của SCTP gửi lên cho ULP. Các thông báo này được gửi qua các Socket riêng rẽ hoặc các kênh báo lỗi. DATA ARRIVE SEND FAILURE NETWORK STATUS CHANGE COMMUNICATION UP COMMUNICATION LOST COMMUNICATION ERROR RESTART SHUTDOWN COMPLETE DATA ARRIVE: Thông báo cho ULP khi có bản tin User được nhận thành công và đã sẵn sàng chuyển lên. Các thông tin kèm theo được chuyển lên cho ULP bao gồm Association ID và Stream ID. SEND FAILURE: thông báo khi một bản tin không thể gửi đi. Các thông tin kèm theo gồm association id, data retrieval id (Số danh định mà SCTP gán cho dữ liệu không được gửi đi hoặc không được xác nhận), cause code (Mã chỉ thị loại lỗi ví dụ như quá hạn thời gian sống, kích thước quá lớn...), context (giá trị này đã được ULP gán cho bản tin khi gửi yêu cầu Send cho SCTP). NETWORK STATUS CHANGE: thông báo khi trạng thái mạng thay đổi ví dụ như liên kết bị hỏng hay đã khôi phục lại liên kết. Các thông tin kèm theo là: association id, destination transport address và new-status (chỉ thị trạng thái mới của liên kết). COMMUNICATION UP: thông báo về một liên kết đã sẵn sàng hoạt động (đã xong thủ tục khởi tạo) hoặc liên kết đã được phục hồi từ trạng thái hư hỏng. Các thông tin kèm theo là: association id, status (chỉ thị loại sự kiện đã xảy ra), destination transport address list, outbound stream count và inbound stream count. COMMUNICATION LOST: Khi một kết nối bị mất hoàn toàn hay khi nhận được chunk Abort, SCTP sẽ gửi thông báo tới ULP. Các thông tin kèm theo bao gồm association id và status (cho biết mất kết nối vì hư hỏng, bị hủy bỏ hay vì kết thúc “mềm” kết nối). Ngoài ra các thông tin sau có thể được kèm theo: data retrieval id, last-acked (TSN cuối cùng được xác nhận bởi đối tác), last-sent (TSN cuối cùng được gửi cho đối tác), Upper Layer Abort Reason (nguyên nhân trong trường hợp bị từ chối khởi tạo). COMMUNICATION ERROR: Khi SCTP nhận được chunk ERROR và quyết định thông báo cho ULP. Các thông tin sau có thể được kèm theo: association id và error info (Thông tin về loại lỗi và các thông tin thêm nhận được từ chunk ERROR). RESTART: Khi SCTP nhận ra bên đối tác đã khởi động lại, nó sẽ thông báo cho ULP, thông tin kèm theo là association id. SHUTDOWN COMPLETE: thông báo này được gửi khi SCTP hoàn thành việc kết thúc “mềm” một kết nối. thông tin kèm theo là association id. KẾT LUẬN Qua quá trình tìm hiểu, nghiên cứu lý thuyết luận văn đã tìm hiểu được một số vấn đề sau: Mô hình và hoạt động của mạng báo hiệu SS7 Cấu trúc và các giao thức báo hiệu trong mạng thế hệ mới (NGN) Quá trình liên kết dữ liệu báo hiệu từ mạng SS7 vào mạng NGN sử dụng giao thức Sigtran (SS7 over IP). Tuy nhiên do đặc thù của báo hiệu, đề tài chỉ đi thiên về lý thuyết nhằm xây dụng một cái nhìn tổng quan, khái quát. Hướng phát triển của đề tài: xây dựng và thực hiện các phương pháp đo kiểm báo hiệu phục vụ cho nhu cầu hiện tại và tương lai. Do giới hạn về trình độ và kiến thức thực tế, chắc chắn tài liệu này không tránh khỏi thiếu sót, rất mong nhận được sự thông cảm và góp ý của thầy cô và các bạn. Xin chân thành cảm ơn! PHỤ LỤC I. MÃ TIÊU ĐỀ CỦA BẢN TIN TUP Nhóm tin báo H0/H1 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 0000 Dự trữ sử dụng cho quốc gia FAM 0001 IAM IAI SAM SAO FSM 0010 GSM COT CCF BSM 0011 GRQ SBM 0100 ACM CHG UBM 0101 SEC CGC NNC ADI CFL SSB UNN LOS SST ACB DPN MPR EUM CSM 0110 ANC ANN CBK CLF RAN FOT CCL CCM 0111 RLG BLD BLA UBL UBA CCR RSC GRM 1000 MGB MBA MGU MUA HGB HBA HGU HUA GRS GRA SGB SBA SGU SUA 1001 Dự trữ CNM 1010 ACC Dự trữ dành cho sử dụng quốc gia và quốc tế 1011 1100 Dự trữ dành cho sử dụng quốc gia 1101 1110 1111 II. CÁC LOẠI BẢN TIN TUP ACB Access Barred Signal ACC Automatic Congestion Control info. mess. Thông tin về tự động điều khiển nghẽn mạng ACM Address Complete Message Bản tin báo kết thúc việc nhận địa chỉ ADI Address Incomplete Signal Bản tin báo việc nhận địa chỉ chưa kết thúc ANC Answer Signal, Charge Bản tin trả lời, tính cước ANN Answer Signal, No Charge Bản tin trả lời, không tính cước ANU Answer Signal, Unqualified Bản tin trả lời, không hạn chế BLA Blocking-acknowledgement signal Tín hiệu chấp nhận chặn BLO Blocking Signal Tín hiệu chặn BSM Backward Set-up Message CBK Clear-back Signal Bản tin yêu cầu giải toả theo hướng về CCF Continuity-Failure Signal CCL Calling party Clear Signal CCM Circuit supervision Message Bản tin kiểm tra mạch CCR Continuity-Check-Request Signal CFL Call-Failure Signal CGC Circuit-Group-Congestion Signal CHG Charging Message CLF Clear-Forward Signal Bản tin yêu cầu giải toả theo hướng đi CNM Circuit Network Management Mess. Group COT Continuity Signal CSM Call Supervisor Mess. Bản tin giám sát cuộc gọi. DPN Digital Path Not provided signal EUM Extended Unsuccessful backward set-up Info. FAM Forward Address Mess. Thông tin địa chỉ hướng đi. FOT Forward Tranfer signal FSM Forward Setup Mess. Bản tin thiết lập hướng đi. GRA Circuit Group Reset-Acknowledgement mess. GRM Circuit Group supervisor mess. GRQ General Request mess. GRS Circuit Group Reset mess GSM General forward set-up info. Mess. HBA Hardware failure oriented group Blocking-Acknowledgement mess. HGB Hardware failure oriented group Blocking mess. HGU Hardware failure oriented group Unblocking mess. HÚA Hardware failure oriented group Unblocking- Acknowledgement mess. IAI Initial Address mess. with addition Infor. Bản tin địa chỉ khởi đầu kèm thông tin phụ trợ IAM Initial Address Mess. Bản tin địa chỉ khởi đầu LOS Line-Out-of-Service signal MBA Maintenance oriented group Blocking-Acknowledgement mess. MGB Maintenance oriented group Blocking mess. MGU Maintenance oriented group Unblocking mess. MPR Misdialled trunk Prefix MUA Maintenance oriented group Unblocking-Acknowledgement mess. NNC National-Network-Congestion signal RAN Reanswer signal RLG Release Guard signal Tín hiệu giải toả bảo vệ RSC Reset-Circuit signal SAM Subsequent Address Mess. Bản tin địa chỉ tiếp theo sau SAO Subsequent Address mess w/ One signal Bản tin địa chỉ tiếp theo với một tín hiệu địa chỉ SBA Software Generated group Blocking-Acknowledgement mess. SBM Successful Backward setup info. Mess. SEC Switching-Equipment-Congestion signal SGB Software Generated group Blocking mess. SGU Software Generated group Unblocking mess. SSB Subcriber-Busy signal SST Send-Special-info.-Tone signal SUA Software generated group Unbloking-Acknowledgement UBA Unblocking-Acknowledgement signal UBL Unblocking signal UBM Unsuccessful Backward setup infor. Mess. UNN Unallocated-Number signal III. CÁC LOẠI BẢN TIN ISUP: * ANSI-ISUP ** ITU-ISUP IV. Ý NGHĨA CÁC BẢN TIN ISUP Bản tin hòan thành địa chỉ (Address Complete Message): Bản tin ACM được gửi theo hướng về nhằm chỉ ra rằng tổng đài này đã nhận được tất cả các tín hiệu địa chỉ cần thiết để định tuyến cuộc gọi tới thuê bao bị gọi. Bản tin trả lời ANM (Answer Message): Bản tin ANM gửi theo hướng về nhằm chỉ ra rằng cuộc gọi đã được trả lời và bắt đầu tính cước cho thuê bao chủ gọi. Bản tin khóa mạch BLO (Blocking Message): Bản tin BLO được gửi tới tổng đài đầu xa để chuyển trạng thái mạch sang trạng thái bận đối với mỗi cuộc gọi xuất phát từ tổng đài này. Nếu như một mạch nào đó được sử dụng trong chế độ song hướng (bothway), tổng đài nhận bản tin BLO có thể vẫn phải nhận các cuộc gọi đến trên mạch này trừ khi chính nó cũng gửi bản tin BLO để khóa mạch. Trong một số trường hợp, bản tin này cũng được sử dụng để khởi tạo lại mạch. Bản tin công nhận khóa mạch BLA (Blocking Acknownledgement Message): Bản tin BLA được sử dụng để trả lời các bản tin khóa mạch. Bản tin tiến trình cuộc gọi CPG (Call Pregress Message): Bản tin CPG được gửi theo hướng về nhằm chỉ ra rằng một sự kiện nào đó xảy ra trong qúa trình thiết lập cuộc gọi và được chuyển tiếp tới thuê bao chủ gọi. Bản tin thông tin cước CRG (Charge Information Message) Bản tin khóa nhóm mạch CGB (Circuit Group Blocking Message): Bản tin CGB gửi tới tổng đài đầu xa để chuyển trạng thái một nhóm mạch sang trạng thái bận đối với các tổng đài xuất phát từ tổng đài đó. Tổng đài đầu xa nhận bản tin CGB phải có khả năng nhận các cuộc gọi đến trên các mạch bị khóa gọi đi này trừ khi chính nó cũng gửi bản tin khóa nhóm mạch đó. Bản tin công nhận khóa nhóm mạch CGBA (Circuit Group Blocking Acknowledgement Message): Bản tin CGBA được gửi đi nhằm trả lời bản tin CGB, chỉ ra rằng nhóm mạch yêu cầu đã bị khóa gọi đi. Bản tin thiết lập lại trạng thái nhóm mạch GRS (Circuit Group Reset Message): bản tin GRS được gửi đi nhằm giải phóng một nhóm mạch. Bản tin công nhận thiết lập trạng thái nhóm mạch GRA (Circuit Group Reset Acknowledgement Message): Bản tin GRA được gửi đi nhằm trả lời bản tin GRS và chỉ ra rằng nhóm mạch yêu cầu đã được thiết lập lại trạng thái. Bản tin mở khóa nhóm mạch CGU (Circuit Group Unblocking Message): Bản tin CGU được gửi tới tổng đài đầu xa nhằm xóa bỏ trạng thái bận tạo ra do bản tin BLO hay CGB trước đó. Bản tin công nhận mở khóa nhóm mạch CGUA (Circuit Group Unblocking Acknowledgement Message): Bản tin CUGA được gửi đi nhằm trả lời bản tin CGU và chỉ ra rằng nhóm mạch yêu cầu đã được mở khóa. Bản tin báo hiệu nhầm lẫn CNF (confusing Message): Bản tin CNF được gửi đi tới tổng đài đầu xa nhằm trả lời một bản tin nào đó nếu như tổng đài không nhận dạng được bản tin hay một phần nào đó của bản tin. Bản tin kết nối CON (Connect Message): Bản tin CON được gửi theo hướng về chỉ ra rằng tổng đài đã nhận được tất cả các tín hiệu địa chỉ cần thiết cho việc định tuyến các cuộc gọi tới thuê bao được gọi và cuộc gọi đã được trả lời. Bản tin liên tục COT (Continuity Message): Bản tin COT được gửi theo hướng chỉ ra rằng có hay không việc kiểm tra trên các mạch trước đó hay một nhóm mạch đã chọn tới tổng đài tiếp theo, bao gồm cả việc kiểm tra đường truyền qua tổng đài này với một mức tin cậy xác định. Bản tin yêu cầu kiểm tra tín hiệu liên tục CCR (Continuity Check Request Message): Bản tin được gửi đi tới tổng đài đầu kia của một mạch yêu cầu cần có thiết bị kiểm tra tính liên tục cho mạch cần kiểm tra. Bản tin từ chối phương tiện FRJ (Facility Reject Message): Bản tin này được gửi đi nhằm trả lời bản tin FAR và chỉ ra rằng yêu cầu phương tiện đã bị từ chối. Bản tin yêu cầu phương tiện FAR (Facility Request Message): Bản tin FAR được gửi từ tổng đài này với tổng đài khác yêu cầu kích họat phương tiện. Bản tin thông tin INF (Information Message): Bản tin này được gửi đi nhằm truyền đạt thông tin liên quan tới cuộc gọi đã được yêu cầu trong bản tin INR. Bản tin yêu cầu thông tin INR (Initial Request Message): Bản tin này được gửi đi nhằm yêu cầu thông tin thông tin liên quan đến cuộc gọi. Bản tin địa chỉ khởi đầu IAM (Initial Address Message): Bản tin được gửi theo hướng chiếm mạch đầu ra và truyền số thuê bao cùng các thông tin khác liên quan tới định tuyến và xử lí cuộc gọi. Bản tin giải phóng REL (Release Message): Bản tin REL có thể được gửi theo hướng đi hoặc hướng về, nó chỉ ra rằng mạch đã được giải phóng và sẵn sàng chuyển sang trạng thái rỗi khi nhận được bản tin RLC. Bản tin hoàn thành giải phóng RLC (Release Complete Message): được gửi theo hướng đi hoặc về để trả lời khi nhận được bản tin REL. Bản tin mạch thiết lập lại trạng thái RSC (Reset Circuit Message): được gửi đi nhằm giải phóng một mạch. Nếu ở phía nhận mạch này đang bị khóa thì thì trạng thái xóa sẽ bị xóa bỏ khi nhận được bản tin này. Bản tin bắt đầu lại RES (Resume Message): được gửi đi theo hướng đi hoặc về nhằm chỉ ra rằng thuê bao chủ gọi hoặc bị gọi được kết nối lại sau khi bị treo. Bản tin địa chỉ tiếp theo SAM (Subsequent Address Message): được gửi đi theo sau bản tin địa chỉ khởi đầu IAM, truyền đạt thêm những thông tin phụ về thuê bao bị gọi. Bản tin SUS (Suspend Message): được gửi đi theo hướng đi hoặc về nhằm chỉ ra rằng thuê bao chủ gọi hoặc bị gọi tạm thời bị ngắt. Bản tin mở khóa UBL (Unblocking Message): được gửi tới tổng đài đầu xa nhằm hủy bỏ trạng thái bận của mạch ở phía tổng đài này gây ra bởi bản tin BLO hay CGB được gửi tới trước đó. Bản tin công nhận mở khóa UBA (Unblocking Acknowledgement Message): được gửi đi nhằm trả lời bản tin UBL. Bản tin thông tin người sử dụng với người sử dụng USR (User to User Information Message): được sử dụng để truyền tải báo hiệu giữa người sử dụng với người sử dụng độc lập với các bản tin điều khiển cuộc gọi. V. CÁC THAM SỐ CỦA ISUP Message Type Code Access Delivery Information 00101110** Access Transport 00000011 Automatic Congestion Level 00100111 Backward Call Indicators 00010001 Business Group 11000110* Call Diversion Information 00110110** Call History Information 00101101** Call Modification Indicators 00010111* Call Reference 00000001 Called Party Number 00000100 Calling Party Number 00001010 Calling Party’s Category 00001001 Carrier Identification 11000101* Carrier Selection Information 11101110* Cause Indicators 00010010 Charge Number 11101011* Circuit Assignment Map 00100101* Circuit Group Characteristic Indicator 11100101* Circuit Group Supervision Message Type Ind. 00010101 Circuit Identification Name 11101000* Circuit State Indicator 00100110 Circuit Validation Response Indicator 11100110* CUG Check Response Indicators 00011100* CUG Interlock Code 00011010 COMMON LANGUAGE 11101001* Connected Number 00100001 Connection Request 00001101 Continuity Indicators 00010000 Echo Control Information 00110111** Egress 11000011* End of Optional Parameters 00000000 Event Information Indicators 00100100 Facility Indicator 00011000 Facility Information Indicators 00011001* Forward Call Indicators 00000111 Freephone Indicators 01000001** Generic Address 11000000* Generic Digits 11000001 Generic Name 11000111* Generic Notification 00101100** Generic Number 11000000** Generic Reference 01000010** Hop Counter 00111101 Index 00011011* Information Indicators 00001111 Information Request Indicators 00001110 Jurisdiction 11000100* Location Number 00111111** MCID Request Indicator 00111011** MCID Response Indicator 00111100** Message Compatibility Information 00111000** MLPP Precedence 00111010** Nature of Connection Indicators 00000110 Network Specific Facilities 00101111** Network Transport 11101111* Notification Indicator 11100001* Operator Services Information 11000010* Optional Backward Call Indicators 00101001 Optional Forward Call Indicators 00001000 Original Called Number 00101000 Originating Line Information 11101010* Origination ISC Point Code 00101011** Outgoing Trunk Group Number 11100111* Parameter Compatibility Information 00111001** Precedence 00111010* Propagation Delay Counter 00110001** Range and Status 00010110 Redirecting Number 00001011 Redirection Information 00010011 Redirection Number 00001100 Redirection Number Restriction 01000000** Remote Operations 00110010 Service Activation 00110011 Service Code Indicator 11101100* Signaling Point Code 00011110 Special Processing Request 11101101* Subsequent Number 00000101 Suspend/resume Indicators 00100010 Transaction Request 11100011* Transit Network Selection 00100011 Transmission Medium Requirement 00000010 Transmission Medium Requirement Prime 00111110** Transmission Medium Used 00110101 User Service Information 00011101 User Service Information Prime 00110000 User Teleservice Information 00110100** User-to-user Indicators 00101010 User-to-user Information 00100000 VI. BẢN TIN CỦA CÁC LỚP THÍCH ỨNG (xUA) M3UA Mã Lớp bản tin Tên Lớp và Loại bản tin Mã Loại bản tin 0 Management (MGMT) messages Error message 0 Notify message 1 1 Transfer messages Payload Data 1 2 SS7 Signaling Network Management (SSNM) messages Destination Unavailable (DUNA) 1 Destination Available (DAVA) 2 Destination State Audit (DAUD) 3 Signaling Congestion (SCON) 4 Destination User Part Unavailable (DUPU) 5 Destination Restricted 6 3 ASP State Maintenance (ASPSM) messages ASP Up 1 ASP Down 2 Heartbeat 3 ASP Up Acknowledge 4 ASP Down Acknowledge 5 Heartbeat Acknowledge 6 4 ASP Traffic Maintenance (ASPTM) messages ASP Active 1 ASP Inactive 2 ASP Active Acknowledge 3 ASP Inactive Acknowledge 4 9 Routing Key Management (RKM) messages Registration Request 1 Registration Response 2 Deregistration Request 3 Deregistration Response 4 SUA Mã Lớp bản tin Tên Lớp và Loại bản tin Mã Loại bản tin 0 Management (MGMT) messages Error message 0 Notify message 1 2 SS7 Signaling Network Management (SSNM) messages Destination Unavailable (DUNA) 1 Destination Available (DAVA) 2 Destination State Audit (DAUD) 3 Signaling Congestion (SCON) 4 Destination User Part Unavailable (DUPU) 5 Destination Restricted 6 3 ASP State Maintenance (ASPSM) messages ASP Up 1 ASP Down 2 Heartbeat 3 ASP Up Acknowledge 4 ASP Down Acknowledge 5 Heartbeat Acknowledge 6 4 ASP Traffic Maintenance (ASPTM) messages ASP Active 1 ASP Inactive 2 ASP Active Acknowledge 3 ASP Inactive Acknowledge 4 7 Connectionless (CL) Messages Connectionless Data Transfer (CLDT) 1 Connectionless Data Response (CLDR) 2 8 Connection-oriented (CO) messages Connection Request (CORE) 1 Connection Acknowledge (COAK) 2 Connection Refused (COREF) 3 Release Request (RELRE) 4 Release Complete (RELCO) 5 Reset Confirm (RESCO) 6 Reset Request (RESRE) 7 Connection-oriented Data Transfer (CODT) 8 Connection-oriented Data Acknowledge (CODA) 9 Connection-oriented Error (COERR) 10 Inactivity Test (COIT) 11 9 Routing Key Management (RKM) messages Registration Request 1 Registration Response 2 Deregistration Request 3 Deregistration Response 4 M2UA Mã Lớp bản tin Tên Lớp và Loại bản tin Mã Loại bản tin 0 Management (MGMT) messages Error message 0 Notify message 1 3 ASP State Maintenance (ASPSM) messages ASP Up 1 ASP Down 2 Heartbeat 3 ASP Up Acknowledge 4 ASP Down Acknowledge 5 Heartbeat Acknowledge 6 4 ASP Traffic Maintenance (ASPTM) messages ASP Active 1 ASP Inactive 2 ASP Active Acknowledge 3 ASP Inactive Acknowledge 4 6 MTP2 User Adaptation (MAUP) messages Data 1 Establish Request 2 Establish Confirm 3 Release Request 4 Release Confirm 5 Release Indication 6 State Request 7 State Confirm 8 State Indication 9 Data Retrieval Request 10 Data Retrieval Confirm 11 Data Retrieval Indication 12 Data Retrieval Complete Indication 13 Congestion Indication 14 Data Acknowledge 15 10 Interface Identifier Management (IIM) messages Registration Request 1 Registration Response 2 Deregistration Request 3 Deregistration Response 4 TÀI LIỆU KHAM KHẢO Bài giảng hệ thống báo hiệu. Nguyễn Khánh Toàn (1996). Bài giảng NGN. Phạm Đình Nguyên. CCITT Common Channel Signaling System Description.AXE Training. Signaling in Telecommunication Networks (2nd Edition). John G. van Bosse & Fabrizio U. Devetak (2006). John Wiley & Sons. Signaling System # 7 (4th Edition). Travis L. Russell (2002). McGraw-Hill. Signaling System No. 7 (SS7/C7): Protocol, Architecture, and Services. Lee Dryburgh & Jeff Hewett (2004). Cisco Press. Signaling System 7. IEC Tutorial. SS7 over IP. Siemens (2004). RFC 4960: Stream Control Transmission Protocol. IETF (2006). RFC 4666: Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). IETF (2006). RFC 3868: Signalling Connection Control Part User Adaptation Layer (SUA). IETF (2004). RFC 4165: Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA). IETF (2005). RFC 3331: Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer (M2UA). IETF (2002). RFC 2719: Framework Architecture for Signaling Transport. IETF (1999). RFC 4916: Connected Identity in the Session Initiation Protocol (SIP). IETF (2007). RFC 3525: Gateway Control Protocol Version 1. IETF (2005). SCTP for Beginners. A. Jungmaier (2003). Computer Networking Technology Group. Rec. Q.762: Signalling System No. 7—ISDN User Part General Functions of Messages and Signals. Rec. Q.700: Introduction to CCITT Signalling System No. 7. ITU-T (1993). Rec. Q.755: Signalling System No. 7 protocol tests. ITU-T (1993).

Các file đính kèm theo tài liệu này:

  • docSS7 over IP.doc
  • rarPresentation.rar
  • pdfSS7 over IP.pdf