VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG CDIT
Bài báo này tập trung phân tích mô hình hỗ trợ phát triển dịch vụ Parlay/OSA, vai trò vị trí của Parlay Gateway trong NGN đồng thời cũng mô tả kiến trúc, các thành phần và các đặc tính kỹ thuật của hệ thống CDiT Parlay Gateway, một sản phẩm của đề tài cấp Tập đoàn “Phát triển hệ thống phần mềm Parlay Gateway” do nhóm NGN Control System thuộc Trung tâm công nghệ thông tin CDiT thực hiện.
1. Một số thuật ngữ và khái niệm
– Call Controller (CC): Thực thể điều khiển cuộc gọi (quản lý thuê bao, phân tích số, định tuyến,…). Trên thực tế đó là các tổng đài PSTN, Softswitch, SIP Server, ….
– Call Agent (CA): Do khái niệm cuộc gọi trong mạng viễn thông hiện nay không chỉ thuần tuý là các cuộc gọi thoại truyền thống mà có thể là các cuộc gọi đa phương tiện (multimedia) nên khái niệm CC cũng được mở rộng thành CA cho phù hợp. Trong bài báo này, chúng tôi sử dụng thống nhất thuật ngữ CA thay cho CC.
– Service Logic (SL): Khái niệm mô tả quy trình hoạt động của một dịch vụ.
– Application Programming Interface (API): Đây là thuật ngữ mô tả giao diện lập trình các ứng dụng máy tính (dịch vụ viễn thông là một loại ứng dụng đặc biệt).
– Service Broker (SB): Là thực thể đứng trung gian làm nhiệm vụ che khuất sự phức tạp của hạ tầng điều khiển đồng thời chuẩn hoá API cấp thấp dưới dạng API cấp cao hơn.
– Application Server (AS): Là máy chủ chứa các SL. Nhiệm vụ của AS là tương tác với CA để điều khiển cuộc gọi theo SL đã mô tả. AS được đặt trong miền mạng của nhà khai thác được gọi là Home AS, ngược lại AS nằm trong miền mạng của nhà khai thác khác được gọi là 3rd-party AS.
Các khái niệm và thuật ngữ trên sẽ được sử dụng trong bài báo này dưới dạng các từ viết tắt như đã diễn giải ở trên.
2. Lịch sử phát triển các kiến trúc phát triển dịch vụ viễn thông
Trong lịch sử phát triển của mạng viễn thông, có rất nhiều kiến trúc hỗ trợ phát triển dịch vụ. Tuy nhiên trong bất kỳ kiến trúc nào, ba khái niệm quan trọng nhất không thể thiếu đó là CA, SL và API. Dựa trên sự tương quan về vị trí giữa hai thành phần này, các kiến trúc phát triển dịch vụ có thể được chia thành: Kiến trúc tích hợp, kiến trúc phân tán đơn giản và kiến trúc thực thể trung gian dịch vụ như trên Hình 1
Kiến trúc tích hợp (Hình 1a) thường gặp trong các mạng viễn thông truyền thống (PSTN, ISDN…) với SL và CA được tích hợp trong cùng một thiết bị điều khiển cuộc gọi (tổng đài PSTN, PABX…). Trong kiến trúc này, API giữa CA và SL thường không được công bố rộng rãi. SL thường do chính nhà cung cấp thiết bị phát triển. Nhà khai thác dịch vụ chỉ được truyền đạt cách quản lý dịch vụ và đưa ra yêu cầu khi cần phát triển dịch vụ mới.
Kiến trúc phân tán đơn giản (Hình 1b): Đặc thù của kiến trúc này là thực thể điều khiển dịch vụ chứa Service Logic đã được tách riêng khỏi thực thể điều khiển cuộc gọi. Trong kiến trúc này, APIs giữa Call Agent và Service Logic thường là được công bố nhưng mức độ chuẩn hoá không cao, mỗi nhà cung cấp, thậm chí mỗi dòng sản phẩm của cùng một nhà cung cấp đều có một APIs riêng, điều này gây trở ngại cho quá trình chuyển đổi nâng cấp hệ thống. Trong một số trường hợp khi thay đổi Call Agent thì cũng phải thay đổi cả Service Logic. Hệ thống điển hình sử dụng kiến trúc này đó là mạng thông minh IN (Intelligent Network). Ngoài ra các API thường khá phức tạp đòi hỏi người phát triển phải có kiến thức về viễn thông chứ không chỉ là những lập trình viên thuần tuý.
Kiến trúc thực thể dịch vụ trung gian: Kiến trúc này đã khắc phục nhược điểm của kiến trúc phân tán đơn giản bằng cách che dấu hoàn toàn các API phức tạp và không đồng nhất của các CA khác nhau để cung cấp cho người phát triển dịch vụ API cấp cao hơn và dĩ nhiên cũng đơn giản hơn và chuẩn hoá hơn. Với kiến trúc này, sự phức tạp đã được đẩy về thực thể trung gian dịch vụ SB. Ngoài chức năng cung cấp API mức cao, SB còn thực hiện chức năng che giấu cấu hình và kéo theo đó là nâng cao khả năng bảo mật của hạ tầng viễn thông. Các hệ thống điển hình cho kiến trúc này có thể kể đến là CGI, JAIN, SPIRIT, TINA… và đáng kể nhất là Parlay/OSA.
3. Kiến trúc phát triển dịch vụ Parlay/OSA
Sự ra đời của hai Parlay và OSA là hoàn toàn độc lập [3]. Tiến trình hợp nhất của Parlay/OSA được mô tả trên Hình 2.
Parlay thuần tuý chỉ là tập API được Parlay Group (gồm 5 thành viên sáng lập là BT (Bristish Telecommunications), Microsoft, Nortel, Siemems và Ulticom) đưa ra phiên bản đầu tiên vào năm 1998 với mục đích hợp nhất các giao diện phát triển ứng dụng dịch vụ viễn thông. Cho đến thời điểm hiện tại Parlay Group đã bao gồm hơn 60 thành viên là các tổ chức chuẩn hoá và các nhà cung cấp thiết bị viễn thông lớn.
Khác với Parlay, OSA được phát triển kết hợp bởi 3GPP và ETSI [3]. OSA ra đời với mục đích ban đầu là hoàn thiện Parlay để đưa vào ứng dụng cho UMTS. Các phiên bản OSA đầu tiên được phát triển dựa chủ yếu trên các phiên bản Parlay 1.2 và Parlay 2.1 với một số bổ sung mới của 3GPP. Tuy nhiên, OSA không chỉ là tập API mà còn là một kiến trúc phát triển dịch vụ và các khuyến nghị về cách thức ánh xạ các API với các giao thức điều khiển ở hạ tầng mạng (MAP, CAP, SIP, INAP…)
Hầu hết các nhà phát triển dịch vụ đã chủ động đưa ra các phiên bản kết hợp (không chính thức) của Parlay và OSA, do có nhiều điểm tương đồng, vào trong các sản phẩm và gọi chung là Parlay/OSA API. Đó cũng chính là nguyên nhân mà Parlay Group và 3GPP/ETSI đã đưa ra phiên bản hợp nhất Parlay 3.0-OSA và tháng 12 năm 2001 đánh dấu sự ra đời chính thức của kiến trúc phát triển dịch vụ Parlay/OSA.
4. Đặc điểm của kiến trúc Parlay/OSA
Ngoài các đặc điểm chung của kiến trúc thực thể dịch vụ trung gian, Parlay/OSA còn có những đặc điểm riêng biệt được mô tả rõ trên Hình 3.
Hình 3: Mô hình Parlay/OSA
Khác với các hệ thống sử dụng kiến trúc phần tử trung gian dịch vụ thông thường khi các AS được đặt trong cùng miền mạng với SB (Hình 2a), các AS trong kiến trúc Parlay/OSA có thể nằm ở miền mạng của nhà khai thác khác (Hình 2b) [1].
Một ưu điểm quan trọng khác của Parlay/OSA chính là tính chuẩn hoá và tính mở. Parlay/OSA API được xây dựng với sự tham gia của hầu hết các tổ chức chuẩn hoá và các tập đoàn viễn thông lớn [1] trong Parlay Group và được bổ sung bởi 3GPP/ETSI. Do được chuẩn hoá, Parlay API cho phép các ứng dụng của nhà phát triển thứ ba (3rd party), thay vì các ứng dụng nội bộ của nhà khai thác, có thể kết nối và tham gia cung cấp dịch vụ. Ngoài ra, với sự hỗ trợ rất mạnh của công nghệ phần mềm, dựa trên Parlay API, công việc phát triển các dịch vụ viễn thông phức tạp được quy về quy trình thiết kế và phát triển các ứng dụng máy tính thuần tuý vốn đã và đang phát triển rất nhanh với nhiều công cụ hỗ trợ rất mạnh (công nghệ hướng đối tượng, công nghệ lập trình phân tán,…).
Thực thể đóng vai trò SB trong kiến trúc Parlay/OSA được gọi là Parlay/OSA Gateway. Vị trí vai trò và kiến trúc của Parlay/OSA Gateway sẽ được trình bày ở phần sau.
5. Vai trò vị trí của Parlay Gateway trong NGN
Trong kiến trúc NGN, thực thể quan trọng nhất trong mô hình Parlay/OSA với vị trí ở “giữa” lớp dịch vụ và lớp điều khiển trong kiến trúc NGN đó là Parlay Gateway như được mô tả trên Hình 4. Parlay/OSA Gateway không phải là một CA của lớp điều khiển vì nó không quản lý dữ liệu thuê bao đầu cuối dịch vụ như các CA mà chỉ quản lý dữ liệu của các thành phần kết nối đến (dữ liệu về các CA của lớp điều khiển, dữ liệu về các AS đăng ký kết nối) và một số dữ liệu nội bộ (sẽ đề cập ở phần 5). Mặt khác, Parlay/OSA cũng không phải là một AS của lớp dịch vụ vì không nó không quản lý SL.
Từ Hình 4 có thể thấy, trong lớp điều khiển:
– Nhìn từ phía ParlayGateway các Call Agent của lớp điều khiển đóng vai trò các proxy server. Các cuộc gọi có dịch vụ thay vì được xử lý ngay tại các Call Agent sẽ được chuyển tiếp đến Parlay Gateway và được trực tiếp xử lý bởi thực thể này theo các logic dịch vụ nhất định.
– Nhìn từ các Call Agent của lớp điều khiển, Parlay Gateway đóng vai trò cầu nối giữa các nền tảng công nghệ mạng khác nhau. Với Parlay Gateway, các thuê của các mạng khác nhau có thể giao tiếp với nhau thông qua các dịch vụ liên mạng.
Trong lớp dịch vụ:
– Nhìn từ phía Parlay Gateway, AS là nơi lưu trữ logic dịch vụ và ra lệnh điều khiển dịch vụ theo logic đó.
– Nhìn từ phía AS, Parlay Gateway là thực thể trung gian duy nhất đóng vai trò cửa ngõ đi vào hạ tầng mạng. Với Parlay Gateway, AS không cần giao tiếp trực tiếp với các Call Agent của hạ tầng mạng và cũng không cần kết nối với nhiều mạng. Dịch vụ được xây dựng trong AS đơn thuần chỉ là các lời gọi hàm từ xa thông qua một môi trường hỗ trợ phát triển ứng dụng phân tán nào đó (middle-ware).
6. Kiến trúc tổng quát hệ thống Parlay/OSA Gateway
Kiến trúc tổng quát của hệ thống Parlay/OSA Gateway trên Hình 5 được mô tả chi tiết trong [1].
Hai khái niệm quan trọng nhất trong kiến trúc của Parlay/OSA Gateway đó là Framework và SCF (Service Control Function):
– SCF: Mỗi tập chức năng trong Parlay/OSA API được đặt tên là một SCF. Mỗi SCF là một thực thể logic trừu tượng hoá các API cấp thấp (các giao thức điều khiển giao tiếp với CA) thành các API cấp cao (Parlay/OSA API). Để làm được điều đó mỗi SCF phải có khả năng kết nối đến một hay nhiều CA của hạ tầng mạng thông qua các giao thức điều khiển tương ứng. Kiến trúc Parlay không chuẩn hoá các giao thức này còn OSA chỉ cũng chỉ đưa ra khuyến nghị. Ví dụ, SCF điển hình nhất, Generic Call Control, sử dụng INAP-CS2 và SIP là các giao thức điều khiển. Dữ liệu chính mà SCF quản lý, mặc dù không được chuẩn hoá, là dữ liệu về địa chỉ, đặc tính của các CA kết nối tới SCF đó. Về vật lý, các SCF có thể đứng độc lập hoặc gộp chung trên cùng một máy chủ.
– Framework: Framework là “cửa ngõ” của Parlay Gateway quản lý các kết nối của các Application tới các SCF. Mỗi hệ thống Parlay/OSA Gateway có thể có nhiều SCF nhưng Framework thì là duy nhất. Có thể coi Framework là một SCF đặc biệt vì nó cũng cung cấp API như các SCF khác nhưng là các API đặc thù quản lý việc đăng nhập của các AS và SCF và hiển nhiên dữ liệu mà Framework quản lý là dữ liệu về địa chỉ và đặc tính của các thực thể logic đó. Ngoài ra Framework không nhất thiết phải kết nối với các CA lớp điều khiển.
Điểm đặc biệt của kiến trúc này là hoàn toàn phân tán với sự hỗ trợ của middle-ware giữa Framework, SCF và AS. Tuy nhiên, kết nối logic giữa AS và các SCF nằm dưới sự quản lý của Framework.
7. Hệ thống CDiT Parlay Gateway
Kiến trúc hệ thống CDiT Parlay Gateway được mô tả trên Hình 6.
Trong giải pháp của chúng tôi đưa ra, Parlay Gateway bao gồm các phân lớp:
– Protocol Adapter Layer: Đây là lớp tương thích với các giao thức điều khiển báo hiệu của hạ tầng mạng viễn thông, có nhiệm vụ tiếp nhận, tiền xử lý các bản tin báo hiệu và chuyển đổi ở lớp 5 (Transaction Layer của mô hình OSI) về mô hình chung (sẽ phân tích ở mục sau) cho từng nhóm API. Đây là lớp rất quan trọng quyết định khả năng tương thích báo hiệu của Parlay Gateway với hạ tầng viễn thông
– SCF Layer: Đây là lõi điều khiển bao gồm Framework và các SCF. Nhiệm vụ của lớp này là chuyển đổi báo hiệu thành các API cấp cao.
– Middleware Layer: Lớp này cung cấp môi trường hỗ trợ phát triển ứng dụng cho Parlay/OSA API.
– Management Layer: Lớp này cung cấp các chức năng và giao diện quản lý hệ thống cho người quản trị.
Giải pháp chúng tôi đưa ra nhằm hướng đến các tiêu chí:
– Về tính khả mở: Kiến trúc chúng tôi đưa ra hoàn toàn mở ở tất cả các lớp. Đầu vào hệ thống có thể là các Protocol Stack (lớp Session), cũng có thể là các SCF.
– Về khả năng nâng cấp: Như đã phân tích trong [1]. Hệ thống được thiết kế theo chiều dọc và phát triển theo chiều ngang. Hay nói cách khác, các tập API sẽ được xây dựng cùng dựa trên kiến trúc phân lớp và được phát triển bổ sung dưới dạng các module độc lập.
Riêng về vấn đề Call Agent và tương thích mạng, giải pháp là nhóm phát triển đưa ra là xây dựng SIP Adapter với lõi điều khiển tương tự như cơ chế của IN để giao tiếp với Softswitch qua giao diện SIP với các ưu điểm rõ rệt:
– Vẫn giao tiếp với Softswitch để tận dụng khả năng tương thích báo hiệu đa dạng của Softswitch.
– Vẫn hỗ trợ giao diện INAP cho ứng dụng Legacy.
– Không đòi hỏi Softswitch sửa đổi INAP khi có yêu cầu bổ sung các đặc điểm mới. (Thực ra thì điều này cũng có thể xảy ra khi SIP thay đổi tuy nhiên sự thay đổi của Softswitch theo SIP gần như là xu thế tất yếu).
– Sẵn sàng tương thích khi có sự chuyển đổi sang mô hình FMC sử dụng kiến trúc hội tụ điều khiển IMS. Khi đó giao diện ISC giữa S-CSCF của IMS Core với Parlay Gateway sử dụng SIP làm giao thức điều khiển duy nhất.
Cấu hình hiện tại của CDiT Parlay/OSA Gateway được mô tả trên Hình 7.
– Về tập chức năng, tại thời điểm hiện tại, CDiT Parlay Gateway hỗ trợ hai tập API quan trọng nhất bao gồm Framework, Generic Call Control dựa trên công nghệ SIP và Generic Messaging sử dụng SMPP và SMTP.
– Về công nghệ Middleware, giải pháp sử dụng hiện tại là CORBA (TAO_CORBA) cho Parlay APIs. Trong tương lai, có thể sử dụng SOAP để hỗ trợ các APIs của tập Parlay X.
– Giao diện quản lý tại thời điểm hiện tại sử dụng giao thức MMI (do CDiT tự phát triển) áp dụng cho tất cả các thành phần của hệ thống.
– Một số ứng dụng đã được phát triển dựa trên Parlay/OSA API bao gồm IP Centrex, Miss-Call Alert, Mail Alert, Web Dial.
8. Về khả năng ứng dụng
Trên quy mô lớn, trên lý thuyết, CDiT Parlay Gateway hoàn toàn có thể tiếp cận các mạng viễn thông lớn của VNPT theo hai hướng:
– Kết hợp trực tiếp với các Call Agent đã triển khai trên mạng lưới để hỗ trợ phát triển dịch vụ. Về nguyên tắc, hướng tiếp cận này có nhiều ưu điểm tuy nhiên sẽ gặp nhiều khó khăn vì để tương thích với nhiều Call Agent của các hãng khác nhau trên mạng lưới đòi hỏi phải tiến hành nhiều thử nghiệm đo kiểm và hợp chuẩn và trong nhiều trường hợp phải thực hiện tương thích khá nhiều giao thức, sẽ gây chồng chéo về mục đích với sản phẩm Softswitch của CDiT đã phát triển. Tuy nhiên nếu đặt mục tiêu thương mại hóa sản phẩm ở quy mô lớn thì đây là một hướng đi cần thiết.
– Với các Call Agent của CDiT đã phát triển mà điển hình là Softswitch hoặc SIP Server, Parlay Gateway có thể được sử dụng trong trường hợp Softswitch của CDiT hoạt động chia tải với các Call Agent khác trên mạng lưới của Tập đoàn. Ưu điểm của phương án này là giải quyết được vấn đề tương thích với Call Agent. Giải pháp này sẽ được áp dụng trong pha thử nghiệm trong phòng thí nghiệm và triển khai thử nghiệm
Trên quy mô vừa và nhỏ, những rào cản đối với Parlay Gateway cũng giảm bớt:
– Về mặt kết nối với hạ tầng viễn thông, vấn đề tương thích Call Agent cũng đơn giản hơn.
– Về mặt dịch vụ, Parlay Gateway thường được tích hợp vào trong các gói sản phẩm cụ thể đặc biệt là các gói dịch vụ hoạt động thuần trên hạ tầng IP (IP Centrex, Mail-Message…). khi đó Parlay Gateway trở thành một khung phát triển ứng dụng rất hiệu quả giúp CDiT đẩy nhanh tốc độ phát triển dịch vụ cũng như tăng cường khả năng chuyên môn hoá trong đội ngũ nghiên cứu phát triển.
Ở thời điểm hiện tại, nhóm phát triển đánh giá đây là hướng triển khai khả thi nhất, tạo điều kiện kiểm nghiệm, đánh giá và hoàn thiện sản phẩm trước khi đưa ra ứng dụng ở các quy mô lớn hơn.
Về khả năng ứng dụng trong tương lai, nếu hoạt động tốt trong thế hệ mạng hiện tại, khi NGN tiến lên kiến trúc hội tụ FMC (Fix Mobile Convergence) ở lớp điều khiển IMS [2], với giao diện SIP, Parlay Gateway có thể sẵn sàng giao tiếp với thực thể S-CSCF của mạng lõi IMS để hỗ trợ phát triển dịch vụ.
9. Kết luận
Như đã đề cập ở trên, mặc dù đang trong giai đoạn thử nghiệm với một số SCFs cơ bản, các kết quả thử nghiệm cho thấy CDiT Parlay Gateway có thể ứng dụng được cho các hệ thống NGN thông qua giao diện SIP. Trong tương lai gần, với quy trình phát triển đã mô tả trong [1] nhóm phát triển sẽ tiến hành bổ sung mở rộng một số tập API khác (Mobility, Management, Online Charging,…) cũng như nghiên cứu cải tiến hiệu năng và khả năng bảo mật nhắm tới mục tiêu đưa CDIT Parlay Gateway tham gia hỗ trợ phát triển dịch vụ trên mạng NGN sắp triển khai của Tập đoàn.
10. Tài liệu tham khảo:
[1]. Đề tài KHCN cấp tập đoàn Phát triển phần mềm Parlay Gateway. Ms: 014 -2006-TĐ-RDP-VT-40.
[2]. The IP Multimedia Concepts and Services in the Mobile Domain. Mikka Poikselka, Gorge Mayer, Hisham Khatabil and Aki Niemi. John Wiley & Sons, Ltd. 2004.
[3]. Next Generation Intelligent Networks, Johan Zuidweg, Artech House, 2002.
Tác giả:
Kỹ sư Cao Minh Thắng tốt nghiệp đại học chuyên ngành Điện tử Viễn thông tại Học viện công nghệ Bưu chính Viễn thông (PTIT) năm 2003. Hiện là học viên cao học tại Học viện công nghệ Bưu Chính Viễn thông.
Nghề nghiệp: Từ năm 2004 đến nay, là nghiên cứu viên thuộc Trung tâm công nghệ thông tin (CDIT) trực thuộc PTIT, hiện là trưởng nhóm nghiên cứu các hệ thống điều khiển trong NGN.
Lĩnh vực nghiên cứu: NGN Control Systems.
Các dự án tham gia: ACD/Call Center, IP-Centrex, IPAS-GSM SMS Gateway System, Parlay/OSA Gateway, NGN Protocols Test-Suite.
Địa chỉ liên hệ: Mr. Cao Minh Thang
Centre for Development of Information Technology, VCCI Building, 2th Floor, 9 Dao Duy Anh Str., Dong Da Dist., Hanoi, Vietnam.
E-mail: thangcm@cdit.com.vn