Truyền tải báo hiệu signalling system number 7 (hệ thống báo hiệu số 7) trong next generation network (mạng thế hệ sau)

ong nhiều luồng với lựa chọn để phân phát theo thứ tự đến của từng bản tin. - lựa chọn ghép nhiều bản tin người vào gói tin SCTP. - khả năng chịu lỗi lớp mạng thông qua việc hỗ trợ multi-homing tại cả hai phía của liên kết. - phân đoạn dữ liệu cho phù hợp với kích thước của MTU. 4.2.3 Các chức năng cung cấp bởi lớp M2UA 4.2.3.1 Sắp xếp Lớp M2UA phải duy trì một ánh xạ của ID giao diện tới một giao diện vật lý trong SG. Giao diện vật lý có thể là V.35, khe thời gian T1, E1... Lớp M2UA cũng duy trì một ánh xạ của các Nhận dạng giao diện tới liên kết SCTP và tới các luồng liên quan trong liên kết. Tiến trình cổng báo hiệu (SGP) ánh xạ một Nhận dạng giao diện tới một luồng/liên kết SCTP chỉ khi một tiến trình server ứng dụng (ASP) gửi một bản tin kích hoạt ASP cho một Nhận dạng giao diện nào đó. Tuy nhiên, quá trình ánh xạ này là động và có thể thay đổi bất cứ khi nào phụ thuộc vào sự thay đổi của trạng thái ASP. Quá trình ánh xạ này thậm chí có thể tạm thời ngừng, ví dụ như trong khi có sự định tuyến lại để khắc phục lỗi của một ASP tới một ASP khác (fail-over). Do đó, SGP phải duy trì trạng thái của AS/ASP và tham chiếu chúng trong quá trình địn tuyến bất cứ bản tin nào tới một AS/ASP. Chú ý rằng chỉ một SGP cung cấp các dịch vụ kết cuối tuyến báo hiệu cho một tuyến SS7. Do đó, trong một SG, một server ứng dụng chỉ được kích hoạt chỉ một SGP tại một thời điểm xác định. Một ví dụ về mối quan hệ giữa một tuyến báo hiệu SS7, Nhận dạng giao diện, AS và ASP trong một SGP như sau: Một SGP có thể hỗ trợ nhiều AS. Một AS lại có thể hỗ trợ nhiều Nhận dạng giao diện. 4.2.3.2 Hỗ trợ sự quản lý của liên kết SCTP giữa các SGP và ASP Lớp M2UA tại SG duy trì trạng thái khả dụng của tất cả các ASP đã được thiết lập cấu hình để quản lý liên kết SCTP và lưu lượng giữa SG và các ASP. Cũng như vậy, trạng thái tích cực/không tích cực của các ASP xa cũng được duy trì. Những ASP tích cực là những ASP đang nhận lưu lượng từ SG. Lớp M2UA có thể được chỉ dẫn bởi sự quản lý nội bộ để thiết lập một liên kết SCTP tới một node M2UA ngang hàng. Điều này có thể đạt được bằng cách sử dụng hàm nguyên thuỷ để yêu cầu, chỉ thị và xác nhận sự thiết lập của một liên kết SCTP với một node M2UA ngang hàng. Lớp M2UA cũng có thể cần thông báo sự quản lý nội bộ tình trạng của liên kết SCTP bên dưới bằng cách sử dụng các hàm nguyên thủy yêu cầu và chỉ thị. Ví dụ, M2UA có thể thông báo sự quản lý nội bộ nguyên nhân để giải phóng một liên kết SCTP, được xác định một cách nội bộ trong lớp M2UA hay bằng một hàm nguyên thuỷ từ SCTP. 4.2.3.3 Trạng thái của các ASP Lớp M2UA trong SG phải duy trì trạng thái của các ASP mà nó hỗ trợ. Trạng thái của một ASP thay đổi bởi nhận được một bản tin ngang hàng hay chỉ thị từ một liên kết SCTP nội bộ. Tại một tiến trình cổng báo hiệu SGP, một danh sách các server ứng dụng có thể chứa các ASP tích cực và không tích cực để hỗ trợ các thủ tục fail-over của ASP. Ví dụ, khi cả ASP cơ bản và ASP dự phòng đều khả dụng, giao thức ngang hàng M2UA được yêu cầu để điều khiển ASP hiện đang kích hoạt. Danh sách thứ tự của các ASP trong một server ứng dụng logic được cập nhật trong SGP để cho thấy ASP hoạt động. Lớp M2UA cũng cần thông báo sự quản lý nội bộ sự thay đổi trạng thái của một ASP hay AS. Điều này có thể thực hiện được bằng cách sử dụng các hàm nguyên thuỷ M-ASP_STATUS hay M-AS_STATUS. 4.2.3.4 Quản lý luồng SCTP SCTP cho phép một số xác định các luồng được mở trong quá trình khởi tạo một liên kết. M2UA phải chịu trách nhiệm đảm bảo việc quản lý một cách hợp lý những luồng này. Bởi bản chất đơn hướng của luồng, lớp M2UA không nhận thức được thông tin luồng từ lớp M2UA ngang hàng với nó. Vì vậy mà phải có phần Nhận dạng giao diện trong tiêu đề bản tin M2UA. Sự sử dụng các luồng SCTP trong M2UA được khuyến nghị để giảm tối đa trễ truyền dẫn và bộ đệm, qua đó, tăng hiệu năng tổng và độ tin cậy của các thành phần báo hiệu. Một luồng SCTP riêng biệt có thể được sử dụng cho mỗi tuyến SS7 hoặc cũng có thể thực hiện chia tuyến SS7 qua một số luồng dựa trên SLS (Signalling Link Selection). Phương thức này có thể thích hợp hơn cho các tuyến SS7 tốc độ cao vì những tuyến này có một số thứ tự 24 bit và số thứ tự luồng là 16 bit. 4.2.3.5 Phối hợp hoạt động quản lý mạng SS7 không theo kiểu luồng Nếu ASP tích cực hiện tại chuyển trạng thái, lớp M2UA trong SGP phải chuyển một chỉ thị về sự không khả dụng của người sử dụng M2UA (MTP3) tới phần quản lý lớp nội bộ. Hành động thực hiện bởi M2UA ở SGP liên quan đến MTP mức 2 phải phù hợp với các đặc tính MTP thích hợp. 4.2.3.6 Điều khiển luồng, điều khiển tắc nghẽn M2UA có thể được thông báo về sự gia tăng hay giảm đi tình trạng nghẽn trong mạng IP bằng cách thực hiện chức năng phụ thuộc (có nghĩa là một chỉ thị từ SCTP). Việc xử lý chỉ thị nghẽn này bởi M2UA được thực hiện một cách độc lập. Tuy nhiên, hành động thực hiện bởi SG phải phù hợp với các đặc tính MTP thích hợp và phải cho phép các chức năng SS7 được duy trì chính xác. 4.2.3.7 Kiểm tra trạng thái tuyến SS7 Sau khi định tuyến lại lưu lượng từ một ASP tới một ASP khác (fail-over), M2UA trong ASP có thể phải kiểm tra trạng thái tuyến SS7 hiện tại để đảm bảo duy trì hoạt động ổn định. M2UA trong SGP phải đáp lại các yêu cầu kiểm tra với thông tin liên quan đến trạng thái hiện tại của tuyến SS7 (đang phục vụ, không phục vụ, trạng thái nghẽn…) 4.2.4 So sánh M2PA và M2UA Một kiến trúc M2PA được chỉ ra ở hình 4.2 ở đây MTP3 của IPSP sử dụng M2PA bên dưới của nó thay thế cho MTP2. Thông tin giữa hai lớp MTP3/MTP2 được xác định bởi cùng các hàm nguyên thuỷ như SS7 MTP3/MTP2. M2PA thực hiện chức năng tương tự như MTP2. Một kiến trúc để so sánh của M2UA được chỉ ra ở hình 4.3. Trong M2UA, MTP3 của MGC sử dụng MTP2 của SG như là lớp SS7 thấp hơn của nó. Cũng như vậy, MTP2 của SG sử dụng MTP3 của MGC như lớp SS7 thấp hơn của nó. Trong SS7, thông tin giữa các lớp MTP3 và MTP2 được xác định bởi các hàm nguyên thuỷ. Trong M2UA, thông in MTP3/MTP2 được xác định là các bản tin M2UA và được gửi qua kết nối IP. Tổng hợp một số so sánh giữa M2PA và M2UA: M2PA M2UA Các bản tin dữ liệu MTP3 Truyền tải bản tin dữ liệu MTP3 Truyền tải bản tin dữ liệu MTP3 Giao diện với MTP3 Giới thiệu một giao diện cao hơn MTP2 tới MTP3 Giới thiệu một giao diện cao hơn MTP2 tới MTP3 Xử lý các hàm nguyên thuỷ Điểm báo hiệu IP xử lý hàm nguyên thuỷ giữa MTP2 và MTP3 Điểm báo hiệu IP truyền tải các hàm nguyên thuỷ MTP3/MTP2 tới MTP2 của SG thông qua chức năng phối hợp hoạt động node để xử lý. Các kiểu tuyến Kết nối SG tới điểm báo hiệu IP là một tuyến SS7 Kết nối từ SG tới điểm báo hiệu IP không phải là một tuyến SS7. Nó là sự mở rộng của MTP2 tới node xa. Mã điểm SG là một node SS7 với một mã điểm SG không phải là một node SS7 và không có mã điểm Các lớp SS7 cao hơn SG có thể có các lớp SS7 cao hơn, ví dụ như SCCP SG không có các lớp SS7 cao hơn vì nó không có MTP3 Quản lý Dựa trên MTP3 Sử dụng các thủ tục quản lý M2UA 4.3 Giao thức lớp thích ứng người sử dụng phần truyền bản tin mức 3 của SS7 (M3UA) 4.3.1 Tổng quan về M3UA M3UA là giao thức hỗ trợ truyền tải bất cứ báo hiệu người sử dụng SS7 MTP3 nào qua mạng IP sử dụng các dịch vụ của SCTP. Các thành phần của giao thức này cũng cho phép hoạt động không theo kiểu luồng của các thực thể ngang hàng người sử dụng MTP3 trong mạng SS7 và mạng IP. Giao thức này được sử dụng giữa một SG và một MGC hay Cơ sở dữ liệu IP, hay giữa các ứng dụng trên nền IP. Nhìn chung, cơ chế phân phát báo hiệu từ một SG tới một MGC hay cơ sở dữ liệu IP phải đáp ứng được các yêu cầu sau: - Hỗ trợ truyền tải tất cả các bản tin người sử dụng MTP3 SS7 (ví dụ như ISUP, SCCP, TUP…) - Hỗ trợ hoạt động không theo kiểu luồng của các thực thể giao thức người sử dụng MTP3. - Hỗ trợ quản lý các liên kết truyền tải SCTP và lưu lượng giữa một SG và một hay nhiều MGC hay các cơ sở dữ liệu IP. - Hỗ trợ chia tải và và khả năng định tuyến lại (fail-over) ở các MGC hay cơ sở dữ liệu IP. - Hỗ trợ thông báo không đồng bộ sự thay đổi trạng thái tới chức năng quản lý. Trong khái niệm truyền tải đơn giản nhất, SG sẽ kết cuối lớp giao thức MTP3, MTP2, phân phát các bản tin ISUP, SCCP và bất cứ bản tin giao thức người sử dụng MTP3 nào khác cũng như là các sự kiện quản lý mạng MTP qua các liên kết truyền tải SCTP tới thực thể ngang hàng người sử dụng MTP3 ở MGC hay cơ sở dữ liệu IP. 4.3.2 Kiến trúc giao thức M3UA Như ta đã tìm hiểu trong chương trước, kiến trúc khung được xác định để truyền báo hiệu chuyển mạch kênh qua mạng IP sử dụng nhiều thành phần, bao gồm một giao thức truyền tải báo hiệu chung và một module thích ứng để hỗ trợ các dịch vụ yêu cầu bởi một giao thức báo hiệu chuyển mạch kênh nào đó từ lớp giao thức bên dưới của nó. Trong kiến trúc khung đó, M3UA được xác định nằm trong module thích ứng người sử dụng MTP3 phù hợp cho việc hỗ trợ truyền tải các bản tin của bất cứ lớp giao thức nào được xác nhận đối với MTP mức 3 như là một người sử dụng MTP. Các lớp giao thức này bao gồm ISUP, SCCP, TUP… Các bản tin TCAP và RANAP được truyền trong suốt bởi giao thức M3UA như là tải của SCCP vì chúng là giao thức người sử dụng SCCP. M3UA sử dụng các dịch vụ của SCTP như là một giao thức truyền tải báo hiệu chung tin cậy bên dưới. Điều này tận dụng được nhiều ưu điểm của SCTP như đã nêu ở phần M2UA. 4.3.3 Các dịch vụ cung cấp bởi lớp M3UA Lớp M3UA tại một ASP hay IPSP cung cấp tập tương đương các hàm nguyên thủy tại lớp cao hơn của nó cho người sử dụng MTP3 như được cung cấp bởi MTP mức 3 cho người sử dụng MTP3 của nó tại một SS7 SEP. Theo cách này, lớp ISUP và SCCP tại một ASP hay IPSP không quan tâm rằng các dịch vụ MTP3 mong muốn được cung cấp từ xa từ một lớp MTP3 tại một SGP, không phải là từ một lớp MTP3 nội bộ. Lớp MTP3 tại một SGP cũng có thể không quan tâm rằng người sử dụng nội bộ của nó thực tế là phần người sử dụng xa qua M3UA. Thực ra, M3UA mở rộng truy nhập tới lớp các dịch vụ MTP3 cho một ứng dụng xa trên cơ sở IP. Lớp M3UA tự nó không cung cấp các dịch vụ MTP3. Tuy nhiên, trong trường hợp nơi ASP được kết nối tới nhiều hơn một SG, lớp M3UA tại một ASP phải duy trì trạng thái của điểm đích SS7 đã được thiết lập và định tuyến các bản tin phụ thuộc vào tình trạng khả dụng hay nghẽn của các tuyến tới những điểm đích đó qua mỗi SG. Lớp M3UA cũng có thể được sử dụng cho báo hiệu điểm - điểm giữa hai tiến trình server IP (IPSPs). Trong trường hợp này, lớp M3UA cung cấp cùng một bộ các hàm nguyên thủy và dịch vụ tại lớp cao hơn của nó như MTP3. Tuy nhiên, trong trường hợp này các dịch vụ MTP3 mong muốn không được cung cấp từ xa bởi một SGP. Các dịch vụ MTP3 không được cung cấp nhưng các thủ tục để hỗ trợ những dịch vụ này là một phần của các thủ tục MTP3 bởi bản chất điêm - điểm đơn giản hoá của IPSP tới quan hệ IPSP. 4.3.3.1 Hỗ trợ truyền tải bản tin người sử dụng MTP3 Lớp MTP3 cho phép truyền tải các hàm nguyên thuỷ qua một liên kết SCTP đã được thiết lập giữa một SGP và một ASP hay giữa các IPSP. Tại một ASP, trong trường hợp có thể đến được điểm đích qua nhiều SGP, lớp M3UA cũng phải chọn lựa qua SGP nào bản tin được định tuyến hay hỗ trợ cân bằng tải qua các SGP, giảm thiểu sự truyền sai thứ tự. Lớp M3UA không có trường thông tin báo hiệu SIF 272 octet như trong giao thức SS7 MTP2. Các khối thông tin lớn hơn có thể được điều chỉnh trực tiếp bởi M3UA/SCTP mà không cần có các thủ tục phân mảnh/tạo gói của lớp cao hơn như SCCP hay ISUP. Tuy nhiên, trong trường hợp của SG, kích thước khối tối đa 272 octet phải được tuân thủ khi phối hợp hoạt động với mạng SS7 mà không hỗ trợ truyền các khối thông tin lớn hơn. Điều này giúp tránh yêu cầu phân mảnh SCCP hay ISUP tại các SGP. Sự giám sát và cấu hình của mạng SS7 xác định giới hạn kích thước khối tối đa. 4.3.3.2 Các chức năng quản lý chủ động Lớp M3UA cung cấp khả năng chỉ thị lỗi ở các bản tin M3UA nhận được và thông báo khi cần thiết sự quản lý nội bộ của M3UA ngang hàng. 4.3.3.3 Phối hợp hoạt động với các chức năng quản lý mạng MTP3 Tại SGP, lớp M3UA cho phép phối hợp hoạt động với các chức năng quản lý MTP3 để hỗ trợ các hoạt động không theo kiểu luồng của các ứng dụng báo hiệu chuyển mạch kênh trong mạng SS7 và mạng IP. Điều này bao gồm: - Cung cấp chỉ thị tới người sử dụng MTP3 tại một ASP rằng không thể đến được điểm đích trong mạng SS7. - Cung cấp chỉ thị tới người sử dụng MTP3 tại một ASP rằng bây giờ có thể đến được điểm đích. - Cung cấp chỉ thị tới người sử dụng MTP3 tại một ASP rằng bản tin tới điểm đích trong mạng SS7 đang ở trong tình trạng nghẽn của SS7. - Cung cấp chỉ thị tới lớp MTP3 tại một ASP rằng tuyến tới điểm đích trong mạng SS7 hiện đang bị cấm. - Cung cấp chỉ thị tới người sử dụng MTP3 tại một ASP rằng thực thể ngang hàng người sử dụng MTP3 hiện đang không khả dụng. Lớp M3UA tại một ASP giữ trạng thái của các tuyến tới điểm đích SS7 xa và có thể khởi tạo một kiểm tra sự khả dụng, tình trạng nghẽn hay bị hạn chế của điểm đích SS7. Thông tin này được yêu cầu từ lớp M3UA tại SGP. Lớp M3UA tại một ASP cũng có thể chỉ thị cho một SG rằng chính nó hay ASP đang bị nghẽn. 4.3.3.4 Hỗ trợ quản lý các liên kết SCTP giữa SGP và ASP Lớp M3UA tại SGP duy trì trạng thái khả dụng của tất cả các ASP xa đã được thiết lập cấu hình để quản lý các liên kết SCTP và lưu lượng giữa các thực thể ngang hàng M3UA. M3UA cũng duy trì trạng thái nghẽn và tình trạng kích hoạt hay không của các ASP xa. Lớp M3UA có thể được hướng dẫn bởi sự quản lý nội bộ để thiết lập một liên kết SCTP tới một node M3UA ngang hàng. Điều này có thể đạt được bằng cách sử dụng các hàm nguyên thủy để yêu cầu, chỉ dẫn và xác nhận sự thiết lập một liên kết SCTP với một node M3UA ngang hàng. Để tránh liên kết SCTP thừa giữa hai node M3UA, một phía (client) phải được ấn định thiết lập liên kết hay thông tin cấu hình M3UA phải được duy trì để phát hiện liên kết thừa. Sự quản lý nội hạt có thể yêu cầu từ lớp M3UA tình trạng của các liên kết SCTP bên dưới bằng cách sử dụng các hàm nguyên thuỷ yêu cầu và xác nhận trạng thái SCTP. M3UA cũng có thể thông báo một cách tự động cho quản lý nội bộ lý do để giải phóng một liên kết, được xác định một cách nội bộ trong lớp M3UA hay bởi hàm nguyên thuỷ từ SCTP. M3UA cũng có thể thông báo cho quản lý nội bộ sự thay đổi trong trạng thái của một ASP hay AS. Điều này có thể đạt được bằng cách sử dụng các hàm nguyên thuỷ phù hợp. 4.3.3.5 Hỗ trợ quản lý kết nối tới nhiều SGP Một ASP có thể được kết nối tới nhiều SGP. Trong trường hợp như vậy, có thể giao tiếp được với một điểm đích SS7 riêng biệt qua nhiều hơn một SGP hay SG, có nghĩa là qua nhiều hơn một tuyến. Vì người sử dụng MTP3 chỉ duy trì trạng thái ở một điểm đích mà không phải trên toàn tuyến, lớp M3UA phải duy trì trạng thái (độ khả dụng, hạn chế, trạng thái nghẽn của tuyến tới đích) của từng tuyến, tổng hợp thành thông tin chung về độ khả dụng hay tắc nghẽn của điểm đích từ trạng thái của từng tuyến, và thông báo cho người sử dụng MTP3 trạng thái này khi nó thay đổi. 4.3.4 Chức năng của M2UA 4.3.4.1 Biểu diễn mã điểm báo hiệu Trong mạng báo hiệu SS7, để có thể định tuyến được, một SG có thể phải chịu trách nhiệm trình bày một tập các node trong mạng IP thành mạng SS7. Bản thân SG là một điểm báo hiệu trong mạng SS7 cũng có thể được đánh địa chỉ với một mã điểm SS7 do mục đích quản lý MTP3. Mã điểm SG cũng có thể được sử dụng cho đánh địa chỉ bất cứ người sử dụng MTP3 nào tại SG chẳng hạn như lớp SCCP nội bộ. Một SG có thể được phân chia về mặt logic để hoạt động trong nhiều mạng SS7. Trong trường hợp như vậy, SG có thể được đánh địa chỉ với một mã điểm trong mỗi mạng, và biểu diễn một tập các node trong mạng IP sang từng mạng SS7. Các server ứng dụng có thể được biểu diễn bởi cùng mã điểm của SG, mã điểm riêng của chính nó hay được nhóm với các server ứng dụng khác vì mục đích dự phòng mã điểm. Một mã điểm đơn có thể được sử dụng để biểu diễn SG cùng với tất cả các server ứng dụng nếu muốn. Nếu một ASP hay nhóm ASP khả dụng đối với mạng SS7 qua nhiều hơn một SG, các ASP sẽ được biểu diễn đặc thù bằng một mã điểm khác biệt so với bất kỳ mã điểm SG nào. Điều này cho phép những SG này có thể được nhìn từ phía mạng SS7 như là những STP, mỗi SG có một tuyến hoạt động tới cùng ASP. Trong điều kiện lỗi khi mà ASP trở nên không khả dụng từ một trong những SG, cách tiếp cận trên cho phép truyền bản tin quản lý tuyến MTP3 giữa mạng SG và SS7, cho phép định tuyến lại SS7 đơn giản thông qua một SG thay đổi mà không phải thay đổi địa chỉ mã điểm đích của lưu lượng SS7 tới ASP. Khi có thể liên lạc với AS nào đó thông qua nhiều hơn một SGP, các Khoá định tuyến tương ứng trong SGP phải đồng nhất. Hình vẽ sau cho thấy một SG có thể được phân chia về mặt logic trong hai mạng 4.3.4.2 Routing Context và Routing Key Khái niệm Việc phân chia bản tin SS7 giữa SGP và server ứng dụng được xác định bằng các Routing Key và Routing Context gắn liền với nó. Một Routing Key là một tập cần thiết các thông số SS7 được sử dụng để lọc các bản tin SS7, trong khi thông số Routing Context là một giá trị nguyên 4 byte được kết hợp với Routing Key theo quan hệ 1:1. Do đó Routing Context có thể được xem như là một chỉ mục tới bảng phân phối bản tin node gửi chứa các Routing Key. Thông tin định tuyến/đánh địa chỉ SS7 có thể trong Routing Key bao gồm OPC, DPC, SIO trong nhãn định tuyến MTP3, hay trường xác định người sử dụng MTP3 (chẳng hạn như ISUP CIC, số phân hệ SCCP ). Một số ví dụ về Routing Key là: DPC, kết hợp của DPC/OPC, kết hợp của DPC/OPC/CIC hay kết hợp của DPC/SSN. Thông tin riêng được sử dụng để xác định một Routing Key M3UA là phụ thuộc vào mạng và ứng dụng. Một tiến trình server ứng dụng ASP có thể được thiết lập cấu hình để xử lý lưu lượng báo hiệu liên quan đến nhiều hơn một server ứng dụng qua một liên kết SCTP. Trong các bản tin quản lý ASP tích cực và không tích cực, lưu lượng báo hiệu bắt đầu hay dừng lại được phân loại bằng các thông số Routing Context. Trong một ASP, thông số Routing Context xác định duy nhất dải các lưu lượng báo hiệu kết hợp với mỗi server ứng dụng và ASP được thiết lập để nhận. Giới hạn của Routing Key Routing Key phải là duy nhất sao cho mỗi bản tin báo hiệu SS7 nhận được phải hoàn toàn phù hợp hay một phần với kết quả định tuyến. Giá trị dải thông số trong một Routing Key không cần thiết phải liên tiếp nhau. Ví dụ, một AS có thể được cấu hình để hỗ trợ xử lý cuộc gọi cho nhiều dải trung kế PSTN mà không được biểu diễn bằng các giá trị CIC liên tục. Quản lý Routing Key và Routing Context Có hai cách để giám sát một Routing Key tại một SGP. Một Routing Key có thể được cấu hình tĩnh bằng cách sử dụng giao diện quản lý thực hiện độc lập hay một cách động bằng các thủ tục đăng ký Routing Key M3UA. Khi sử dụng giao diện quản lý để cấu hình Routing Key, chức năng phân phối bản tin trong SGP không bị giới hạn trong tập các thông số mà các thuật toán phân phối bản tin khác có thể được sử dụng. Phân phối bản tin tại SGP Để chuyển bản tin nhận được từ mạng MTP3 SS7 tới đích phù hợp trong mạng IP, SGP phải thực hiện chức năng phân phối bản tin bằng cách sử dụng thông tin từ bản tin người sử dụng MTP3. Để hỗ trợ phân phối bản tin này, SGP có thể duy trì một bản tương đương của bảng biên dịch địa chỉ mạng, sắp xếp thông tin bản tin SS7 tới một server ứng dụng AS cho một ứng dụng riêng biệt và một dải lưu lượng. Điều này có thể đạt được bằng cách so sánh các thành phần của bản tin SS7 đến với các Routing Key hiện tại đã được xác định trong SGP. Những Routing Key này đến lượt nó có thể sắp xếp trực tiếp vào một AS cho phép bởi một hay nhiều ASP. Những ASP này cung cấp thông tin trạng thái động liên quan đến độ khả dụng, khả năng xử lý lưu lượng và tắc nghẽn tới SGP bằng cách sử dụng các bản tin quản lý khác nhau xác định trong giao thức M3UA. Danh sách các ASP trong một AS được thiết lập động, không tính đến độ khả dụng, khả năng xử lý lưu lượng và trạng thái nghẽn của từng ASP trong danh sách, cũng như là những sự thay đổi cấu hình hay cơ chế định tuyến lại chống lỗi có thể. Thông thường, một hay nhiều ASP được kích hoạt (có nghĩa là xử lý lưu lượng) trong AS nhưng trong trường hợp chuyển tiếp hay lỗi nào đó thì có thể không có ASP nào được kích hoạt mà khả dụng cả. Các kịch bản quảng bá, chia tải và dự phòng được hỗ trợ. Khi không có Routing Key nào phù hợp của bản tin SS7 đến, cơ chế xử lý mặc định có thể được xác định. Giải pháp có thể là cung cấp một AS mặc định tại SGP mà định hướng tất cả lưu lượng chưa được chỉ định tới một (hay nhiều) các ASP mặc định, hay bỏ bản tin và thông báo cho quản lý lớp. Phân phối bản tin tại ASP ASP phải lựa chọn một SGP để định hướng một bản tin tới mạng SS7. Điều này được thực hiện băng cách quan sát mã điểm đích DPC (và các thành phần khác có thể của bản tin đầu ra, chẳng hạn như giá trị SLS). ASP cũng không quan tâm xem là Routing Context được kích hoạt hay không. 4.3.4.3 Phối hợp hoạt động SS7 và M3UA Trong trường hợp phối hợp hoạt động SS7 và M3UA, lớp thích ứng M3UA được thiết kế để cho phép mở rộng các hàm nguyên thuỷ xác định bởi MTP3. Lớp SS7 cổng báo hiệu SG chịu trách nhiệm kết cuối MTP mức 3 của giao thức SS7 và cung cấp sự mở rộng trên cơ sở IP tới người sử dụng của nó. Từ phía mạng SS7, SG phải truyền và nhận các bản tin SS7 MSU tới và từ mạng PSTN qua giao diện mạng SS7 chuẩn, sử dụng phần truyền bản tin SS7 MTP để cung cấp sự truyền dẫn tin cậy những bản tin này. Tại một giao diện mạng SS7 chuẩn, sử dụng các tuyến báo hiệu MTP mức 2 không phải là khả năng duy nhất. Các tuyến tốc độ cao trên cơ sở ATM cũng có thể được sử dụng với các dịch vụ của Lớp thích ứng ATM báo hiệu SAAL. Các giao diện IP cũng hoàn toàn có thể bằng cách sử dụng các dịch vụ của M2UA hay M2PA. Các bản tin được kết cuối tại STP hay SEP. Sử dụng các dịch vụ của MTP3, SG có khả năng thông tin với các SEP SS7 xa trong mô hình tựa kết hợp. Trong mô hình này STP có thể được sử dụng trên tuyến giữa SEP và SG. Phối hợp hoạt động SS7 và M3UA tại SG SGP cung cấp phối hợp hoạt động về mặt chức năng của chức năng truyền tải giữa mạng SS7 và mạng IP bằng cách cũng hỗ trợ lớp thích ứng M3UA. Nó cho phép truyền tải các bản tin báo hiệu người sử dụng MTP3 tới và từ một ASP trên nền IP, nơi mà có lớp giao thức người sử dụng MTP ngang hàng. Để quản lý người sử dụng SS7, các giao thức người sử dụng MTP3 tại ASP phải nhận thông tin chỉ thị về độ khả dụng của điểm báo hiệu SS7, tình trạng nghẽn SS7 và tình trạng không khả dụng phần người sử dụng xa như là tại một node SEP SS7. Để thực hiện điều này, các hàm nguyên thuỷ phù hợp được nhận tại giao diện lớp cao hơn MTP3 tại SG cần được truyền tới giao diện lớp thấp hơn người sử dụng MTP3 xa tại ASP. Các bản tin quản lý MTP3 không được đóng gói như là trường dữ liệu của bản tin DATA và được gửi từ SG tới ASP hay từ ASP tới SG. SG phải nhận những bản tin này và tạo bản tin M3UA phù hợp. Server ứng dụng (AS) Các nhóm AS chịu trách nhiệm cung cấp sự hỗ trợ chung cho một hay nhiều lớp cao hơn SS7. Nhìn từ phía mạng SS7, Các nhóm quản lý điểm báo hiệu SPMC cung cấp sự hỗ trợ đầy đủ cho các dịch vụ lớp cao hơn cho một mã điểm xác định. Ví dụ, một SPMC cung cấp cáckhả năng MGC có thể hỗ trợ đầy đủ cho ISUP (và bất cứ người sử dụng MTP nào khác tại mã điểm của SPMC) cho một mã điểm cho trước. Trong trường hợp một ASP được kết nối tới nhiều SGP, lớp M3UA phải duy trì trạng thái của điểm đích SS7 đã được thiết lập cấu hình và gửi các bản tin phụ thuộc vào trạng thái hạn chế/tắc nghẽn/khả dụng của các tuyến đường tới điểm đích SS7. 4.3.4.4 Mô hình dự phòng bảo vệ AS Tất cả các bản tin người sử dụng MTP3 (ví dụ ISUP, SCCP) phù hợp với Routing Key giám sát tại một SGP thì được sắp xếp vào một AS. AS là một tập tất cả các ASP gắn với một Routing Key xác định. Mỗi ASP trong tập này có thể được kích hoạt, không kích hoạt hay không khả dụng. ASP được kích hoạt sẽ xử lý lưu lượng, còn các ASP không kích hoạt được dùng để dự phòng. Mô hình định tuyến lại chống lỗi hỗ trợ dự phòng "n+k", trong đó n là số ASP tối thiểu xử lý lưu lượng và k là số ASP khả dụng để thay thế khi cần. 4.3.4.5 Điều khiển dòng Sự quản lý nội hạt tại một ASP có thể phải dừng lưu lượng qua một liên kết SCCP để tạm thời để liên kết không phục vụ hoặc để tiến hành kiểm tra hay bảo dưỡng. Chức năng này có thể được lựa chọn để được sử dụng để điều khiển việc bắt đầu truyền lưu lượng tại một liên kết SCTP khả dụng mới. 4.3.4.6 Điều khiển tắc nghẽn Lớp M3UA được thông báo về tình trạng tắc nghẽn cục bộ hay trên mạng IP bằng chức năng thực hiện phụ thuộc (ví dụ như một chỉ thị phụ thuộc thực hiện từ SCTP). Tại một ASP hay IPSP, lớp M3UA chỉ thị tắc nghẽn tới người sử dụng MTP3 nội bộ bằng hàm nguyên thuỷ để yêu cầu các đáp ứng phù hợp của lớp cao hơn. Khi một SG xác định rằng sự truyền tải bản tin SS7 tới Nhóm quản lý điểm báo hiệu SPMC gặp tình trạng tắc nghẽn thì SG có thể tạo ra các bản tin quản lý được điều khiển bởi chức năng truyền tải MTP3 tới node SS7 gốc bởi các thủ tục tắc nghẽn của các chuẩn MTP3 liên quan. Việc tạo ra các bản tin quản lý MTP3 SS7 từ một SG là một chức năng phụ thuộc thực hiện. Lớp M3UA tại một ASP hay IPSP có thể chỉ thị tình trạng tắc nghẽn cục bộ tới thực thể ngang hàng M3UA với một bản tin SCON. Khi một SG nhận được bản tin tắc nghẽn (SCON) từ một ASP, và SG xác định rằng một SPMC hiện tại đang bị nghẽn, nó có thể tạo các bản tin quản lý được điều khiển bởi chức năng truyền tải MTP3 tới các điểm đích SS7 liên quan phụ thuộc vào các thủ tục điều khiển tắc nghẽn của các chuẩn MTP3 liên quan. 4.3.4.7 Sắp xếp luồng SCTP Lớp M3UA tại cả SGP và ASP đều hỗ trợ việc gán lưu lượng báo hiệu vào các luồng trong một liên kết SCTP. Lưu lượng yêu cầu truyền tuần tự phải được gán vào trong một luồng. Để thực hiện được điều này, lưu lượng người sử dụng MTP3 có thể được gán vào các luồng riêng biệt, ví dụ như dựa trên giá trị SLS trong nhãn định tuyến của MTP3 hay chỉ số ISUP CIC, tất nhiên là phải tuân theo số lượng tối đa các luồng hỗ trợ bởi liên kết SCTP bên dưới. 4.3.4.8 Mô hình Client/Server SGP và ASP được khuyến nghị có thể hỗ trợ hoạt động của cả client và server. Các điểm đầu cuối ngang hàng sử dụng M3UA phải được cấu hình sao cho một cái luôn luôn thực hiện chức năng của client và cái còn lại thực hiện chức năng của server khi khởi tạo các liên kết SCTP. Xu hướng mặc định là để SGP đóng vai trò của server trong khi ASP là client. Trong trường hợp này, ASP phải khởi tạo liên kết SCTP tới SGP. Trong trường hợp thông tin giữa IPSP cũng tương tự như vậy. Số cổng gán cho người sử dụng đã đăng ký SCTP và TCP cho M3UA là 2905. 4.3.5 Các cấu hình sử dụng điển hình 4.3.5.1 Truyền tải bản tin ISUP Trong trường hợp này, SGP cung cấp chức năng phối hợp hoạt động tại node (NIF) cho phép MGC trao đổi các bản tin báo hiệu SS7 với các SEP của mạng SS7. Chức năng NIF trong SGP phục vụ như là một giao diện trong SGP giữa MTP3 và M3UA. Chức năng này không có giao thức ngang hàng rõ ràng nào với cả MGC hay SEP. Nó cũng cung cấp thông tin về tình trạng của mạng tới một hay cả hai phía của mạng. Với các mục đích trong SGP, tại lớp NIF, các bản tin báo hiệu số 7 có điểm đích là MGC được nhận như là các hàm nguyên thuỷ chỉ thị MTP-TRANSFER từ giao diện lớp cao hơn MTP3, biên dịch thành các hàm nguyên thủy yêu cầu MTP-TRANSFER và gửi tới chức năng phân phối bản tin nằm tại M3UA để định tuyến tiếp tới điểm đích IP cuối cùng. Các bản tin nhận được từ các chức năng sắp xếp và biên dịch địa chỉ mạng trong M3UA như là các hàm nguyên thuỷ chỉ thị MTP-TRANSFER được gửi tới giao diện lớp cao hơn MTP3 như là các hàm nguyên thuỷ yêu cầu MTP-TRANSFER để định tuyến MTP mức 3 tới một SS7 SEP. Để cung cấp thông tin trạng thái mạng SS7, NIF cũng phân phối các hàm nguyên thuỷ chỉ thị phù hợp nhận từ giao diện lớp cao hơn MTP3 tới chức năng quản lý tại M3UA. Thêm vào đó, các điểm đích hạn chế cũng có thể được thông tin từ quản lý mạng MTP tới chức năng quản lý tại M3UA. 4.3.5.2 Truyền tải SCTP giữa các IPSP Trong mô hình này, không có SG nào được sử dụng. Các bản tin SCCP được trao đổi trực tiếp giữa hai IPSP trong mạng IP mà có các giao thức người sử dụng SCCP chẳng hạn như RANAP hay TCAP. Không cần có chức năng phối hợp mạng SS7 trong trường hợp này, do đó không có thông tin trạng thái quản lý mạng MTP3 cho các giao thức người sử dụng SCCP và SCCP để xem xét. Tất cả các hàm nguyên thuỷ chỉ thị từ lớp M3UA tới lớp SCCP phải xem xét trạng thái của liên kết SCTP và mạng IP bên dưới và các thông tin về tắc nghẽn nhận được từ đầu xa. 4.3.5.3 Truyền tải giữa SP và ASP qua SGP Trong trường hợp này, SGP chứa một lớp giao thức SS7 SCCP có thể thực hiện chức năng Biên dịch tiêu đề chung GTT để các bản tin được đánh điạ chỉ về mặt logic tới SG SCCP. Nếu kết quả của GTT cho bản tin SCCP tạo ra một SS7 DPC hay địa chỉ DPC/SSN của một thực thể ngang hàng SCCP trong miền IP, hàm nguyên thuỷ yêu cầu MTP-TRANSFER kết quả được gửi tới chức năng sắp xếp và biên dịch địa chỉ mạng ở M3UA để tiếp tục định tuyến tới đích IP cuối cùng. Tương tự như vậy, giao thức SCCP trong SCP có thể thực hiện các dịch vụ SCCP GTT cho bản tin được đánh địa chỉ logic tới nó từ thực thể SCCP ngang hàng trong mạng IP. Trong trường hợp này, các hàm nguyên thuỷ chỉ thị MTP-TRANSFER được gửi từ chức năng sắp xếp và biên dịch địa chỉ mạng tại M3UA tới SCCP để thực hiện chức năng GTT. Nếu kết quả của GTT tạo ra địa chỉ của một thực thể SCCP ngang hàng trong mạng SS7 thì hàm nguyên thuỷ yêu cầu MTP-TRANSFER kết quả được gửi tới MTP3 để phân phát tới node SS7. Có thể chức năng SCCP GTT tại SGP như trên có thể tạo ra địa chỉ của thực thể ngang hàng SCCP trong mạng IP và hàm nguyên thuỷ yêu cầu MTP-TRANSFER kết quả phải được gửi trả lại lớp M3UA để phân phát tới đích đến trong mạng IP. Bên trong SGP, điều này có thể đạt được bằng cách sử dụng chức năng phối hợp hoạt động node trong SGP mà thực sự ở bên dưới SCCP và định tuyến các bản tin chỉ thị / yêu cầu MTP-TRANSFER tới / từ cả MTP3 và lớp M3UA, dựa trên SS7 DPC hay thông tin địa chỉ DPC/SSN. Chức năng phối hợp hoạt động node này không có giao thức ngang hàng thực sự nào với cả ASP và SEP. Chú ý rằng các dịch vụ và giao diện cung cấp bởi lớp M3UA là như trong cấu hình truyền tải bản tin ISUP và các chức năng thực hiện trong thực thể SCCP là trong suốt đối với lớp M3UA. Các chức năng giao thức SCCP không được tạo ra trong giao thức M3UA. 4.4 Giao thức lớp thích ứng người sử dụng SCCP (SUA) 4.4.1 Tổng quan về SUA SUA là một giao thức được dùng để truyền tải bất kỳ báo hiệu người sử dụng SCCP nào qua mạng IP, chẳng hạn như MAP, INAP, RANAP..., sử dụng Giao thức truyền dẫn điều khiển luồng SCTP. Giao thức được thiết kết theo kiểu module và đối xứng, cho phép nó có thể làm việc trong các kiến trúc mạng khác nhau, chẳng hạn như kiến trúc từ một SG tới một điểm báo hiệu IP cũng như là kiến trúc báo hiệu IP ngang hàng. Cơ chế phân phối bản tin phải đáp ứng được những yêu cầu sau: - Hỗ trợ truyền tải các bản tin phần người sử dụng SCCP. - Hỗ trợ dịch vụ không kết nối SCCP. - Hỗ trợ các dịch vụ hướng kết nối SCCP. - Hỗ trợ hoạt động của các thực thể giao thức người sử dụng SCCP. - Hỗ trợ quản lý các liên kết truyền tải SCCP giữa các SG và node báo hiệu IP. - Hỗ trợ các node báo hiệu IP phân tán. - Hỗ trợ thông báo không đồng bộ sự thay đổi trạng thái cho chức năng quản lý. 4.4.2 Kiến trúc truyền tải báo hiệu Kiến trúc khung cho truyền tải báo hiệu chuyển mạch kênh qua mạng IP – SIGTRAN sử dụng nhiều thành phần bao gồm một giao thức IP, một giao thức truyền tải báo hiệu chung và một module thích ứng để hỗ trợ các dịch vụ cho một giao thức báo hiệu mạng chuyển mạch kênh riêng biệt nào đó từ lớp giao thức bên dưới của nó. Nhìn chung, kiến trúc SUA được xây dựng theo kiểu ngang hàng peer – to – peer. Trong phần tiếp theo, ta xem xét kiến trúc cho phối hợp hoạt động từ SS7 tới IP để truyền tải hướng kết nối và không kết nối. Trong trường hợp này, giả sử rằng ASP khởi tạo thiết lập liên kết SCTP với SG. 4.4.2.1 Kiến trúc giao thức cho truyền tải không kết nối Trong kiến trúc này, các lớp SUA và SCCP giao tiếp với nhau trong SG. Cần phải có chức năng phối hợp hoạt động giữa các lớp SCCP và SUA để cung cấp sự truyền tải các bản tin người sử dụng cũng như là các bản tin quản lý. SG đóng vai trò là điểm đầu cuối Trong trường hợp này, các bản tin SCCP không kết nối được định tuyến bằng mã điểm (PC) và số phân hệ (SSN). Phân hệ được xác định bởi SSN và Routing Context được coi như là nội bộ trong SG. Điều này có nghĩa là từ quan điểm của mạng SS7, người sử dụng SCCP được đặt tại SG. SG đóng vai trò là điểm chuyển tiếp Chức năng GTT được thực hiện tại SG trước khi điểm đến của bản tin được xác định. Vị trí thực tế của người sử dụng SCCP không liên quan đến mạng SS7. GTT tạo ra một "tập thực thể SCCP" mà từ đó có thể nhận được một server ứng dụng AS. Sự lựa chọn AS được dựa trên địa chỉ SCCP bên bị gọi (và có thể các thông số SS7 khác phụ thuộc vào việc triển khai). 4.4.2.2 Kiến trúc giao thức cho truyền tải hướng kết nối Trong kiến trúc này, các lớp SCCP và SUA chia sẻ một giao diện trong tiến trình cổng báo hiệu SGP để kết hợp hai phiên kết nối cần thiết cho việc truyền tải dữ liệu hướng kết nối giữa SEP và ASP. Cả hai phiên kết nối được thiết lập khi định tuyến các bản tin yêu cầu kết nối từ điểm cuối báo hiệu SEP qua SGP tới ASP và ngược lại. Việc định tuyến bản tin yêu cầu kết nối được thực hiện giống như là đã được miêu tả trong phần trước. 4.4.2.3 Kiến trúc toàn IP Kiến trúc này có thể được sử dụng để mang một giao thức sử dụng các dịch vụ truyền tải của SCCP trong mạng IP. Nó cho phép phát triển mạng một cách mềm dẻo, đặc biệt là khi không cần thiết phải tương tác với mạng báo hiệu cũ. Kiến trúc này loại bỏ nhu cầu chức năng cổng báo hiệu. 4.4.2.4 Kiến trúc fail – over ASP Như ta đã tìm hiểu từ những chương trước, fail – over là khả năng định tuyến lại lưu lượng báo hiệu khi được yêu cầu đến một ASP, hay một nhóm ASP thay thế trong một AS trong trường hợp lỗi hay không khả dụng của một ASP hiện đang được sử dụng. Giao thức SUA hỗ trợ chức năng fail – over ASP để hỗ trợ độ khả dụng cao hơn của khả năng xử lý biên dịch. Một AS có thể được xem như là một danh sách tất cả các ASP đã được thiết lập cấu hình hay đăng ký để xử lý các bản tin người sử dụng SCCP trong một dải xác định thông tin định tuyến gọi là Routing Key. Một hay nhiều ASP trong danh sách thông thường có thể được kích hoạt để xử lý lưu lượng trong khi các ASP khác không được kích hoạt nhưng khả dụng để thay thế trong trường hợp lỗi hay không khả dụng của các ASP đang kích hoạt. 4.4.3 Các dịch vụ cung cấp bởi lớp SUA 4.4.3.1 Hỗ trợ truyền tải các bản tin người sử dụng SCCP SUA hỗ trợ truyền tải các bản tin của người sử dụng SCCP. Lớp SUA tại SG và tại ASP hỗ trợ truyền tải không theo kiểu luồng các bản tin người sử dụng giữa SG và ASP. 4.4.3.2 Hỗ trợ lớp giao thức SCCP Phụ thuộc vào người sử dụng SCCP được hỗ trợ, SUA hỗ trợ 4 lớp giao thức SCCP có thể một cách trong suốt. Các lớp giao thức được xác định như sau: - Giao thức lớp 0 cung cấp truyên tải không thứ tự các bản tin người sử dụng SCCP theo cơ chế không kết nối. - Giao thức lớp 1 cho phép người sử dụng SCCP lựa chọn việc phân phát tuần tự các bản tin người sử dụng SCCP theo cơ chế không kết nối. - Giao thức lớp 2 cho phép truyền tải song hướng các bản tin người sử dụng SCCP bằng cách thiết lập một kết nối báo hiệu cố định hay tạm thời. - Giao thức lớp 3 cho phép các đặc tính của giao thức lớp 2 cùng với chức năng điều khiển dòng và xác định các bản tin bị mất hay sai thứ tự. Giao thức lớp 0 và 1 thực hiện các dịch vụ SCCP không kết nối. Giao thức lớp 2 và 3 thực hiện các dịch vụ SCCP hướng kết nối. 4.4.3.3 Các chức năng quản lý chủ động Lớp SUA cung cấp khả năng để chỉ thị lỗi trong các bản tin giao thức SUA và để cung cấp thông báo cho chức năng quản lý nội bộ và các thực thể ngang hàng xa nếu cần thiết. 4.4.3.4 Phối hợp hoạt động với các chức năng quản lý mạng SCCP SUA sử dụng các bản tin quản lý ASP sẵn có để xử lý trạng thái ASP. Sự phối hợp hoạt động với các bản tin quản lý SCCP bao gồm DUNA, DAVA, DAUD, DRST, DUPU hay SCON khi nhận được các bản tin SSP, SSA, SST hay SSC tại ASP thích hợp. Những hàm nguyên thuỷ sau được gửi giữa các chức năng quản lý SUA và SCCP trong SG khi có các sự kiện xảy ra trong mạng IP và SS7. 4.4.3.5 Hỗ trợ quản lý giữa SGP và ASP Lớp SUA cung cấp chức năng phối hợp hoạt động với các chức năng quản lý SCCP tại SG để hoạt động giữa mạng chuyển mạch kênh và mạng IP. Nó phải: - Cung cấp chỉ thị cho người sử dụng SCCP tại một ASP rằng không thể liên lạc được với một node / thực thể ngang hàng SS7. - Cung cấp chỉ thị cho người sử dụng SCCP tại một ASP rằng có thể liên lạc được với một node / thực thể ngang hàng SS7. - Cung cấp chỉ thị tắc nghẽn cho người sử dụng tại ASP. - Cung cấp khởi tạo kiểm tra điểm cuối SS7 tại SG. 4.4.3.6 Chức năng chuyển tiếp Để đạt được mục đích về độ phân cấp của mạng, SUA có thể được phát triển với một chức năng chuyển tiếp để xác định liên kết SCTP chặng tiếp theo tới điểm đích SUA. Sự xác định chặng tiếp theo có thể được dựa trên thông tin tiêu đề chung (ví dụ như chuẩn đánh số E.164) tương tự như SCCP GTT trong mạng SS7. Nó cũng có thể được dựa trên thông tin tên node chủ (Hostname), địa chỉ IP hay mã điểm chứa trong địa chỉ bên bị gọi. Điều này cho phép độ phân cấp, tin cậy và mềm dẻo lớn hơn trong các ứng dụng triển khai rộng rãi của SUA. Sự sử dụng chức năng chuyển tiếp hay không là phụ thuộc vào quyết định triên khai mạng. 4.4.4 Các chức năng được cung cấp bên trong lớp SUA Để thực hiện khả năng chuyển tiếp và đánh địa chỉ, SUA sử dụng một chức năng sắp xếp địa chỉ (AMF). AMF được yêu cầu khi một bản tin được nhận tại giao diện đầu vào. AMF chịu trách nhiệm phân tích địa chỉ ở trong bản tin SCCP/SUA đầu vào tới liên kết SCTP tới đích trong mạng IP. AMF sẽ lựa chọn liên kết SCTP thích hợp dựa trên thông tin Routing Context / Routing Key đã có. Đích đến có thể là node SUA cuối hay node SUA chuyên tiếp. Routing Key tham chiếu đến một AS, nơi mà có một hay nhiều ASP xử lý lưu lượng cho AS. Độ khả dụng và trạng thái của ASP được xử lý bởi các bản tin quản lý SUA ASP. Thông tin định tuyến / địa chỉ SS7 có thể bao gồm một Routing Key có thể là OPC, DPC, SIO trong nhãn định tuyến MTP3, số phân hệ SCCP hay ID biên dịch. Địa chỉ IP và tên host cũng có thể được sử dụng như là thông tin Routing Key. 4.4.4.1 Sắp xếp địa chỉ tại SG Thông thường, một hay nhiều ASP được kích hoạt trong AS nhưng trong những trường hợp chuyển tiếp hay lỗi nào đó, có thể không có ASP nào được kích hoạt. SGP sẽ đệm các bản tin thuộc về AS này trong thời gian T(r) hay cho đến khi một ASP trở lại khả dụng. Khi không có ASP nào khả dụng trước khi hết thời gian T(r), SGP sẽ đưa tất cả các bản tin ra khỏi bộ đệm và khởi tạo các thủ tục từ chối hay trả lại phù hợp. Nếu không có sơ đồ địa chỉ phù hợp cho bản tin đến, một cơ chế xử lý mặc định có thể được xác định. Các giải pháp có thể là cung cấp một AS mặc định để định hướng tất cả lưu lượng chưa được cung cấp vị trí cho một tập các ASP mặc định hay bỏ bản tin và cung cấp thông báo cho chức năng quản lý. 4.4.4.2 Sắp xếp địa chỉ tại ASP Để chuyển bản tin tới mạng SS7, ASP có thể thực hiện một sự sắp xếp địa chỉ để chọn SGP thích hợp cho mỗi bản tin. Điều này được thực hiện bằng cách đọc DPC và các thành phần khác trong bản tin đi, trạng thái mạng SS7, độ khả dụng SGP, các bảng cấu hình Routing Context. Một SG có thể bao gồm một hay nhiều SGP. Tuy nhiên, không có bản tin SUA nào được sử dụng để quản lý trạng thái của một SGP. Bất cứ khi nào tồn tại một liên kết SCTP tới một SGP, nó được coi như là khả dụng. Cũng như vậy, mỗi SGP của một SG thông tin với một ASP liên quan đến một AS cung cấp một kết nối SS7 đồng nhất tới ASP này. 4.4.4.3 Chức năng sắp xếp địa chỉ tại một node chuyển tiếp Chức năng chuyển tiếp được thực hiện khi: - Định tuyến trên tiêu đề chung (Gloal Title). - Định tuyến trên tên node (Hostname). - Định tuyến trên SSN và PC hay SSN và địa chỉ IP và địa chỉ không phải là của node chuyển tiếp. Việc biên dịch / quyết định những thông tin địa chỉ trên tạo ra một trong những kết quả sau: - Định tuyến trên SSN: ID của liên kết SCTP tới node đích, SSN và Routing Context và / hoặc địa chỉ IP. - Định tuyến trên GT: ID liên kết SCTP tới node chuyển tiếp tiếp theo, GT mới và SSN và / hoặc Routing Context. - Định tuyến trên Hostname: ID liên kết SCTP tới node chuyển tiếp tiếp theo. Hostname mói và SSN và / hoặc Routing Context. - Một người sử dụng SUA nội bộ (node đầu cuối / chuyển tiếp kết hợp). Để tránh việc lặp vòng, một bộ đếm chặng SS7 được sử dụng. Node đầu cuối gốc (là một node IP hay SS7) lập giá trị của bộ đếm chặng SS7 thành giá trị nhỏ nhất (15 hay ít hơn). Mỗi lần chức năng chuyển tiếp được thực hiện trong mộ node trung gian hay chuyển tiếp, bộ đếm chặng SS7 được giảm xuống 1 đơn vị. Khi giá trị này đạt đến 0, các thủ tục trả lại hay từ chối được thực hiện với lý do "vi phạm bộ đếm chặng". 4.4.4.4 Sắp xếp luồng SCTP SUA hỗ trợ các luồng SCTP. SG và AS cần phải duy trì một danh sách SCTP và những người sử dụng SUA để sắp xếp. Người sử dụng SCCP yêu cầu truyền tải bản tin tuần tự cần được gửi qua một luồng với việc phân phát có thứ tự. SUA sử dụng luồng 0 cho các bản tin quản lý SUA. Việc phân phát tuần tự có thể được sử dụng để dự phòng cho việc yêu cầu phân phối bản tin quản lý. Việc lựa chọn luồng dựa trên lớp giao thức sau: - Giao thức lớp 0: SUA có thể lựa chọn cơ chế phân phát không thứ tự. Luồng được chọn được dựa trên thông tin lưu lượng khả dụng đối với SGP và ASP. - Giao thức lớp 1: SUA phải lựa chọn cơ chế phân phát không có thứ tự. Luồng được lựa chọn được dựa trên các thông số thứ tự cung cấp bởi lớp cao hơn thông qua các giao diện nguyên thuỷ và thông tin lưu lượng khác có ở SGP hay ASP. - Giao thức lớp 2 và 3: SUA phải lựa chọn việc phân phát tuần tự. Luồng được chọn được dựa trên các tham khảo nội bộ về các kết nối và thông tin lưu lượng khác có ở SGP và ASP. 4.4.4.5 Điều khiển dòng Sự quản lý nội hạt tại một ASP có thể phải dừng lưu lượng qua một liên kết SCCP để tạm thời để liên kết không phục vụ hoặc để tiến hành kiểm tra hay bảo dưỡng. Chức năng này có thể được lựa chọn để được sử dụng để điều khiển việc bắt đầu truyền lưu lượng tại một liên kết SCTP khả dụng mới. 4.4.4.6 Quản lý tắc nghẽn Lớp SUA được thông báo về tình trạng tắc nghẽn cục bộ hay trên mạng IP bằng chức năng thực hiện phụ thuộc (ví dụ như một chỉ thị phụ thuộc thực hiện từ SCTP). Tại một ASP hay IPSP, lớp SUA chỉ thị tắc nghẽn tới người sử dụng SCCP nội bộ bằng hàm nguyên thuỷ để yêu cầu các đáp ứng phù hợp của lớp cao hơn. Khi một SG xác định rằng sự truyền tải bản tin SS7 gặp tình trạng tắc nghẽn thì SG có thể tạo ra các bản tin tắc nghẽn SS7 SCCP tới node SS7 gốc bởi các thủ tục tắc nghẽn của các chuẩn SCCP liên quan. Việc tạo ra các bản tin quản lý SCCP SS7 từ một SG là một chức năng phụ thuộc thực hiện. Lớp SUA tại một ASP hay IPSP có thể chỉ thị tình trạng tắc nghẽn cục bộ tới thực thể ngang hàng SUA với một bản tin SCON. Khi một SG nhận được bản tin tắc nghẽn (SCON) từ một ASP, và SG xác định rằng một điểm cuối hiện đang bị nghẽn, nó có thể tạo các thủ tục điều khiển tắc nghẽn của các chuẩn SCCP liên quan. 4.4.5 So sánh M3UA và SUA M3UA SUA Các tính chất của SCCP Các điểm báo hiệu được yêu cầu để hỗ trợ các đặc tính khác nhau của SCCP nếu nó phải tương tác với các hệ thống quốc gia khác Vấn đề này bị loại trừ khi sử dụng SUA Độ phức tạp khi thực hiện M3UA cần các dịch vụ của SCCP Việc loại trừ SCCP làm giảm độ phức tạp của node mạng (việc thực thi tốt như việc quản lý), do đó làm giảm cước phí Về mặt định tuyến Trong M3UA các bản tin được điều khiển từ mã điểm tới mã điểm SUA cho phép mạng IP định tuyến các bản tin sử dụng thông tin tiêu đề toàn cục Về mặt đánh địa chỉ Sử dụng M3UA, mỗi node IP được yêu cầu phải có địa chỉ IP và mã điểm đã được ấn định dành cho nó Sử dụng SUA, mỗi node IP không tiêu thụ tài nguyên mã điểm Các dịch vụ ISUP Được hỗ trợ Không được hỗ trợ Như chúng ta thấy, nhìn chung, SUA là một giải pháp tốt hơn. SUA cung cấp sự mềm dẻo và linh hoạt hơn nhiều để thực hiện một kiến trúc mạng toàn IP khi so với dùng SCCP hay M3UA. Việc đánh địa chỉ hiệu quả và khả năng định tuyến của SUA có thể làm giảm đáng kể độ trễ truyền tải báo hiệu. 4.5 Cấu trúc bản tin M2PA, M2UA, M3UA, SUA M2PA, M2UA, M3UA, SUA (gọi chung là xUA, xPA) có cấu trúc bản tin tương tự như nhau. Bản tin xUA, xPA bao gồm một tiêu đề chung và theo sau bởi một hoặc nhiều thông số độ dài thay đổi được định nghĩa bởi kiểu bản tin. Cấu trúc của tiêu đề chung bản tin xUA, xPA như sau: Ý nghĩa của các trường trong tiêu đề này: - Phiên bản (Version): gồm 8 bit, phiên bản của lớp tương thích xUA, xPA. - Dự phòng (Spare): phần dự phòng gồm 8 bit. Nó phải được thiết lập thành toàn 0 ở phía gửi và phía thu sẽ phải bỏ qua phần này. - Lớp bản tin (Message Class): gồm 8 bit, chỉ thị lớp bản tin. Các bản tin có thể là: bản tin điều khiển, bản tin truyền tải, bản tin quản lý mạng báo hiệu SS7, bản tin bảo dưỡng trạng thái ASP, bản tin bảo dưỡng lưu lượng ASP… - Kiểu bản tin (Message Type): gồm 8 bit, chỉ thị kiểu bản tin. Đối với mỗi kiểu bản tin khác nhau, ví dụ như: bản tin tương thích người sử dụng MTP2, bản tin duy trì trạng thái tiến trình server ứng dụng, bản tin quản lý lưu lượng tiến trình server ứng dụng... thì các bit chỉ thị lại có ý nghĩa khác nhau. - Độ dài bản tin (Message Length): phần này xác định độ dài của bản tin theo octet, bao gồm cả phần tiêu đề. Phần này phải bao gồm của các byte độn thông số nếu cần. - Khuôn dạng thông số độ dài thay đổi: bản tin xUA bao gồm một tiêu đề chung và có thể theo sau là các thông số độ dài thay đổi được định nghĩa bởi kiểu bản tin. Các thông số độ dài thay đổi chứa trong một bản tin được xác định trong một khuôn dạng giá trị độ dài thẻ như sau: Các thông số bắt buộc phải được đặt trước các thống số lựa chọn trong bản tin. + Thẻ thông số (Parameter Tag): trường này gồm 16 bit xác định loại thông số. Nó nhận các giá trị từ 0 đến 65534. Các thông số chung được sử dụng bởi các lớp thích ứng trong dải từ 0x00 đến 0xFF. Các thông số xác định M2UA trong dải từ 0x300 đến 0x3FF. + Độ dài thông số (Parameter Length): 16 bit, chứa kích thước của thông số theo byte, bao gồm Thẻ thông số, độ dài thông số, và trường giá trị thông số. Do đó, một thông số với trường giá trị thông số độ dài 0 phải có trường độ dài là 4. Độ dài thông số không bao gồm byte độn. + Giá trị thông số (Parameter Value): độ dài thay đổi. Trường giá trị thông số chứa thông tin thực sự được truyền trong thông số. Tổng độ dài của thông số phải là bội của 4 byte. Nếu độ dài của thông số không là bội của 4 byte thì phía gửi phải đệm thêm vào sau trường giá trị thông số các byte toàn không. Độ dài của phần độn thêm không bao gồm trong trường độ dài thông số. Phía gửi không được đệm thêm quá 3 byte. Phía thu sẽ bỏ qua những byte đệm này. KẾT LUẬN Mạng thế hệ sau NGN đang được nghiên cứu, chuẩn hoá bởi các tổ chức viễn thông lớn trên thế giới nhằm đáp ứng nhu cầu càng tăng về tính mở, sự tương thích và linh hoạt để cung cấp đa dịch vụ, đa phương tiện với các tính năng ngày càng mở rộng. Mạng viễn thông Việt Nam đang ngày càng phát triển để đáp ứng các nhu cầu mới trong nền kinh tế hội nhập thế giới và việc phát triển mạng viễn thông lên NGN là việc làm bức thiết nhằm đáp ứng các nhu cầu này. Quá trình xây dựng và phát triển mạng NGN phải được tiến hành từng bước, có tính đến sự tương thích và phối hợp với nền tảng mạng hiện tại. Trên cơ sở phân tích đó đồ án đã tiến hành được các nội dung sau: Giới thiệu tổng quan về mạng NGN, mô hình NGN của một số tổ chức viễn thông lớn; một số khái niệm về phối hợp báo hiệu giữa mạng PSTN và mạng NGN. Tóm tắt những vấn đề cơ bản nhất của hệ thống báo hiệu số 7 và lý do để tiếp tục triển khai sử dụng hệ thống báo hiệu này trên nền mạng mới, nền IP của mạng NGN. Mô tả chồng giao thức SIGTRAN và giao thức SCTP; yêu cầu và nguyên nhân dẫn đến sự phát triển của những giao thức này. Tìm hiểu về các giao thức nằm tại phân lớp thích ứng của chồng giao thức SIGTRAN. Do mạng NGN vẫn đang đang trong quá trình xây dựng, phát triển và chuẩn hoá nên việc triển khai SIGTRAN để truyền tải báo hiệu số 7 qua mạng NGN phần nhiều vẫn phụ thuộc vào từng nhà cung cấp giải pháp và thiết bị. Trên cơ sở các kết quả đạt được của đồ án, có thể nhận thấy còn một số vấn đề cần được nghiên cứu tiếp như: Nghiên cứu sâu hơn về hoạt động của SIGTRAN, sự phối hợp hoạt động của nó với các giao thức khác. Nắm bắt và bám sát tình hình triển khai cũng như nghiên cứu về giao thức trên thế giới. Nghiên cứu sâu hơn về các yêu cầu bảo mật của SIGTRAN. Giải quyết được các vấn đề này sẽ có rất ý nghĩa trong việc thực hiện những bước tiếp theo của quá trình đi lên xây dựng mạng NGN từ mạng PSTN hiên tại, đồng thời cung cấp được nhiều dịch vụ mới với độ tin cây và an toàn lớn hơn. TÀI LIỆU THAM KHẢO [1] NGN 2004 Project Description, Version 3, ITU, 12 February 2004. [2] Eurescom Project P1109 “Next Generation Network: The service offering standpoint”, 11-2001. [3] ThS. Nguyễn Thị Thanh Kỳ, Bài giảng báo hiệu trong mạng viễn thông, Học viện công nghệ bưu chính viễn thông, 1999. [4] Ericsson, Common Channel Signalling, 1992. [5] Uyless Black, ISDN and SS7 Architecture for Digital Signalling Networks, Prentice Hall, 1997. [6] “VNPT Lab trial NGN - Scope of work” Alcatel, 11/2003. [7] Dick Knight, Broadband Signalling Explained, John Wiley & Sons, 2000. [8] IETF RFC 2719: " Framework Architecture for Signalling Transport", October 1999. [9] IETF RFC 2960: "Stream Control Transmission Protocol", October 2000. [10] IETF RFC 3331: "Signalling System 7 Message Transfer Part 2 – User Adaptation Part", September 2002. [11] IETF RFC 3332: "Signalling System 7 Message Transfer Part 3 – User Adaptation Part", September 2002. [12] IETF RFC 3868: "Signalling Connection Control Part User Adaptation Layer", October 2004. [13] IETF Draft: "Signalling System 7 Message Transfer Part 2 – User Peer-to-peer Adaptation Layer", February 2005. [14] [15] [16] [17] [18]