Môi trường kiến tạo dịch vụ dựa trên giao diện mở

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG





Ngô Thanh Bình


MÔI TRƯỜNG KIẾN TẠO DỊCH VỤ
DỰA TRÊN GIAO DIỆN MỞ


Chuyên ngành: KỸ THUẬT ĐIỆN TỬ
Mã số: 60.52.70

TÓM TẮT LUẬN VĂN THẠC SĨ


HÀ NỘI - 2013




Luận văn được hoàn thành tại:
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG


Người hướng dẫn khoa học: ……………………………………………………………
(Ghi rõ học hàm, học vị)

Phản biện 1: ……………………………………………………………………………

Phản biện 2: …………………………………………………………………………




Luận văn sẽ được bảo vệ trước Hội đồng chấm luận văn thạc sĩ tại Học viện Công nghệ
Bưu chính Viễn thông
Vào lúc: giờ ngày tháng năm


Có thể tìm hiểu luận văn tại:
- Thư viện của Học viện Công nghệ Bưu chính Viễn thông

MỞ ĐẦU
Một trong những điều khác biệt của mạng NGN so với mạng viễn thông hiện hữu là
cơ chế, phương pháp phát triển và triển khai dịch vụ. Nếu như trong mạng viễn thông truyền
thống, việc phát triển chủ yếu dựa vào các nhà cung cấp thiết bị và hạ tầng mạng thì trong
mạng NGN với môi trường dịch vụ mở (OSE – Open Service Environment) khả năng kiến
tạo dịch vụ (bao gồm cả nghiên cứu – phát triển và triển khai dịch vụ) chia đều cho cả nhà
cung cấp thiết bị, hạ tầng mạng, bên thứ ba cung cấp dịch vụ và thậm chí cho cả khách
hàng. Trong môi trường dịch vụ mở OSE, các giao diện mở giữ một vài trò rất quan trọng
và cùng với các công cụ phát triển liên quan trong xây dựng một mạng kiến trúc dịch vụ mở
OSA, trong đó các giao diện lập trình ứng dụng API (Application Programming Interface)
và những nghiên cứu phát triển Parlay được nghiên cứu tìm hiểu kỹ lưỡng trong luận văn
này.
Phạm vi của luận văn là tiếp cận, nghiên cứu cơ chế, phương pháp kiến tạo dịch vụ
trong mạng NGN bao gồm tổ chức hệ thống, các yêu cầu kỹ thuật cần thiết tối thiểu và lợi

ích mang lại từ môi trường kiến tạo dịch vụ mở.
Đối tượng nghiên cứu của luận văn là mô hình thực thi kiến trúc dịch vụ mở OSA
bao gồm các giao diện mở, các công cụ phát triển và cách thực thi phát triển dịch vụ trong
điều kiện thực tế.
Phương pháp nghiên cứu của luận văn là việc nghiên cứu lý thuyết thông qua các tài
liệu kỹ thuật , các tiêu chuẩn về OSE của ITU-T, 3GPP và việc kiến tạo các dịch vụ dựa trên
môi trường mô phỏng.
Nội dung của luận văn gồm 3 chương:
Chương I: Môi trường dịch vụ mở OSE trong mạng NGN là các kiến thức tổng quan
về xu thế phát triển dịch vụ trong mạng viễn thông, môi trường dịch vụ mở OSE do ITU-T
đề xuất và xu thế hội tụ dịch vụ trong môi trường NGN-IMS.
Chương II: Môi trường kiến tạo dịch vụ dựa trên giao diện mở Parlay/OSA là nội
dung chủ đạo của luận văn. Trong chương này đề cập tới các giao diện mở, giao diện lập
trình ứng dụng API, mô hình kiến tạo dịch vụ Parlay/OSA. Trong kiến tạo dịch vụ mở theo
Parlay/OSA, nghiên cứu khung làm việc (Framework), các dịch vụ logic và các chức năng
được thực thi trong Parlay/OSA.
Chương III: Kiến tạo dịch vụ dựa trên nền Parlay/OSA là quá trình kiến tạo dịch vụ
trên nền Parlay/OSA. Trong chương này là các dịch vụ trên nền Parlay/OSA API, môi
trường kiến tạo dịch vụ bao gồm ngôn ngữ lập trình, các phần mềm mô phỏng ứng dụng,
các thư viện hỗ trợ. Trong chương này cũng đề cập đến các vấn đề trong triển khai dịch vụ
trong thực tế.
Cuối cùng tôi xin gửi lời cảm ơn chân thành tới người hướng dẫn trực tiếp là TS. Lê
Ngọc Giao cùng các thầy cô khoa Kỹ thuật điện tử đã tận tâm giúp đỡ tôi hoàn thành tốt
luận văn này.


1

CHƯƠNG 1: MÔI TRƯỜNG DỊCH VỤ MỞ OSE TRONG MẠNG
NGN

1.1 Xu hướng phát triển dịch vụ trong mạng viễn thông
Viễn thông phát triển từ đầu những năm 1990 với hệ thống mạng GSM và các dịch
vụ cơ bản đơn giản như gọi thoại, gửi SMS, truyền số liệu tốc độ thấp. Cùng với sự phát
triển của hệ thống mạng viễn thông, các dịch vụ mạng viễn thông cũng ngày càng được cải
thiện và nâng cao đồng thời là sự ra đời của cách dịch vụ mới như wap, truyền số liệu tốc độ
cao, dịch vụ tương tác… đáp ứng nhu cầu đa dạng và phong phú cho người sử dụng.

Hình 1.1: Lịch sử phát triển của mạng viễn thông.
Tính đa dạng của yêu cầu dịch vụ và mong muốn các dịch vụ được triển khai trong
khoảng thời gian ngắn nhất yêu cầu phải có một cơ sở hạ tầng mạng đầy đủ, điều này khó có
thể được đáp ứng trong điều kiện hiện nay. Do đó việc kết hợp các cơ sở hạ tầng cũ mới với
nhau chính là giải pháp được lựa chọn nhằm đáp ứng tối đa nhu cầu của người sử dụng. Các
tổ chức tiêu chuẩn hóa viễn thông như ITU-T, IETF, 3GPP, ETSI… đã đưa ra các mô hình
mạng hội tụ nhằm giải quyết vấn đề này.
Như vậy có thể thấy rõ rằng các mạng di động, cố định, không dây đều hội tụ với
nhau trên môi trường toàn IP. Và cùng với xu hướng hội tụ mạng, 3GPP cũng đưa ra xu
hướng phát triển dịch vụ như sau:
2

Hướng thoại Thông minh

Hình 1.3: Xu hướng phát triển dịch vụ.
Càng phát triển thì tính đa dạng của dịch vụ càng được thể hiện rõ, đo đó một môi
trường kiến trúc mở là rất cần thiết và quan trọng, nó sẽ giúp cho các dịch vụ được tạo ra và
triển khai một cách nhanh chóng, đáp ứng nhu cầu đa dạng của người sử dụng.
1.2 Môi trường dịch vụ mở OSE
Môi trường dịch vụ mở OSE cung cấp các tiện ích cho phép kiến tạo dịch vụ nhanh
và mềm dẻo, thực thi và quản lí dịch vụ dựa trên các giao diện chuẩn. Việc sử dụng các giao
diện chuẩn sẽ cho phép các dịch vụ dựa trên NGN OSE dễ dàng tái sử dụng và có khả năng
linh động cao trên mạng cũng như tăng khả năng tiếp cận cho các nhà phát triển và cung cấp

ứng dụng.
Môi trường dịch vụ mở có các đặc điểm sau:
- Mềm dẻo trong phát triển ứng dụng và các tiện ích được cung cấp bởi nhà cung cấp
NGN, nhà cung cấp ứng dụng và các nhà cung cấp dịch vụ khác.
- Tiếp cận các tiện ích thông qua giao diện mạng ứng dụng chuẩn hóa ANI được định
nghĩa trong ITU-T Y.2012
- Tính di động và tái sử dụng của các tiện ích trong mạng (và từ các mạng khác tới
NGN hoặc từ NGN tới mạng khác).
3

- Thúc đẩy tạo ra các tiện ích mới từ các công nghệ không phải trong môi trường
NGN.

Hình 1.4: Môi trường dịch vụ mở trong NGN.
OSE cho phép các ứng dụng sử dụng các tài nguyên hoặc các dịch vụ của NGN được
cung cấp thông qua giao diện mạng ứng dụng ANI. Các nhà cung cấp ứng dụng hoặc các
nhà phát triển có thể tạo và cung cấp các ứng dụng mới thông qua các giao diện chuẩn hóa
tại ANI.
1.3 Giao diện mở trong mạng viễn thông
Ngày nay, các dịch vụ, ứng dụng hoặc thông tin do một cá nhân cung cấp thường hạn
chế và khá sơ sài. Giao diện mở của NGN sẽ cho phép tất cả người sử dụng có thể trở thành
một nhà cung cấp chia sẻ nội dung của họ với người sử dụng khác. Chẳng hạn, khi xem một
chương trình TV, nội dung của người dùng có thể được thêm vào chương trình và phát
chồng lên chương trình gốc trong điều kiện nhất định.
NGN là xu hướng phát triển tất yếu của mạng viễn thông thế giới trong hiện tại và
tương lai. Nó tích hợp cả ba mạng lưới: mạng PSTN, mạng không dây và mạng số liệu
(Internet) vào một mô hình thống nhất để hình thành một mạng chung, thông minh, hiệu quả
trên nền tảng IP.
4

Hình 1.5: Kiến trúc dịch vụ trong mạng NGN.
Sự phân chia các lớp dịch vụ và truyền tải cho phép nhà khai thác thêm, nâng cấp
hoặc loại bỏ dịch vụ mà không cần can thiệp vào mạng truyền dẫn.
Giao diện mở 1 giữa phần tạo dịch vụ và triển khai dịch vụ cho phép chuẩn hóa cách
thức tạo dịch vụ, điều này giúp tạo ra sự linh động cho nhà cung cấp dịch vụ cũng như
người sử dụng.
Giao diện mở 2 giữa mạng lõi và mạng truy nhập cho phép:
· Thêm hoặc loại bỏ mạng truy nhập mà không cần phải thay đổi mạng lõi.
· Cung cấp dịch vụ với chất lượng khác nhau thông qua tất cả các mạng truy
nhập.
Hiện nay, hầu hết các nhà mạng đều quản lý quá trình tạo và triển khai dịch vụ nhằm
tối đa lợi nhuận. Tuy nhiên, trong tương lai, các yêu cầu về dịch vụ IP như: chính phủ điện
tử, học tập trực tuyến, ngân hàng trực tuyến … sẽ chiếm phần lớn. Khi đó, giao diện mở sẽ
cho phép các bên thứ ba phát triển và triển khai các ứng dụng này.

5

CHƯƠNG 2: MÔI TRƯỜNG KIẾN TẠO DỊCH VỤ DỰA
TRÊN GIAO DIỆN MỞ PARLAY/OSA
2.1 Kiến trúc dịch vụ mở
Trong NGN, dịch vụ không tồn tại mãi mãi, một dịch vụ xuất hiện rồi bị loại bỏ
nhưng mạng thì vẫn tồn tại. Do đó, việc tạo ra dịch vụ phải được chuẩn hóa và được giấu
trong sự phức tạp của mạng và chúng ta không cần thiết phải hiểu cấu trúc của mạng mà vẫn
có thể tạo ra được các dịch vụ, ứng dụng… Để làm được điều này chúng ta cần:
Các API mở (Giao diện lập trình ứng dụng) giữa lớp ứng dụng và lớp dịch vụ. Các
API mở cung cấp chuẩn hóa cho các ứng dụng để thiết lập, thực hiện cuộc gọi, gửi tin SMS
hoặc lấy vị trí của một thuê bao. Các API được lập trình bằng ngôn ngữ Java và khá dễ dàng
sử dụng. Các API mở cho phép chuẩn hóa và tạo dịch vụ dễ dàng các dịch vụ hay ứng dụng
độc lập với mạng.

Hình 2.1: Giao diện mở và cho phép tạo dịch vụ.
Trong môi trường mạng NGN, các dịch vụ dựa trên giao diện mở và kiến trúc mạng
sẽ cho phép sự mở rộng vô cùng lớn cho nhà vận hành, nhà cung cấp dịch vụ và khách
hàng.
Một nhà vận hành mạng sẽ không nhất thiết là nhà cung cấp dịch vụ.
Một nhà vận hành mạng sẽ không nhất thiết là nhà vận hành mạng từ đầu cuối tới
đầu cuối nữa, nó có thể chỉ là nhà vận hành mạng truy nhập hoặc truyền tải.
Các dịch vụ là các ứng dụng IT được mạng hóa bao gồm viễn thông, quảng bá và
dịch vụ về IP.
6

Một nhà cung cấp dịch vụ cũng có thể là người dùng cuối hoặc bên cung cấp thứ ba.
Một khách hàng có thể là cá nhân, công ty, hộ gia đình hoặc là một chiếc xe. Một nhà
cung cấp dịch vụ thứ ba cũng có thể được coi như là một khách hàng đặc biệt sử dụng các
dịch vụ cơ bản của mạng như thiết lập cuộc gọi, thông tin vị trí để cung cấp các dịch vụ cao
hơn tới người dùng cuối.
2.2 Các giao diện mở
2.2.1 Truy nhập dịch vụ mở OSA
2.2.2 Parlay/OSA
Cho tới hiện nay, các dịch vụ viễn thông và các ứng dụng được triển khai trong mạng
hầu hết sử dụng công nghệ mạng IN. Ví dụ về các ứng dụng như dịch vụ mạng riêng ảo
VPN hay dịch vụ chuyển hướng cuộc gọi như chuyển hướng cuộc gọi khi bận. Với khả
năng trong cả IT và viễn thông, nó trở thành một thách thức để tạo ra dịch vụ và khai thác
trên cả hai miền.
Parlay/OSA chính là câu trả lời cho các thách thức này. Parlay/OSA được chuẩn hóa,
bảo mật và là một giao diện mở giữa IT và viễn thông. Bạn có thể thực thi các ứng dụng của
mình trên miền IT và cũng sử dụng các tiện ích trong mạng viễn thông.

Hình 2.3: Kiến trúc mạng logic.

7

Bảng 1: Các thành phần trong Parlay/OSA.
Phần#

SCF Mô tả Ghi chú
1 General
Chứa thông tin và phương thức
được sử dụng

2 Common data
Định dạng dữ liệu được sử dụng
trong các phần khác

3 Framework
Định nghĩa các chức năng cơ bản
như nhận thực, SCF khám phá,
SCF đăng ký, quản lý lỗi…

4 Call Control
Định nghĩa điều khiển cuộc gọi
từ cơ bản tới hội nghị đa phương
tiện.
Cuộc gọi hội nghị đa
phương tiện không
nằm trong 3GPP
Rel.4 OSA
5 User Interaction
SCF nhận thông tin về người

dùng cuối, thông báo, gửi tin
nhắn…

6
User location/User
status
SCF nhận thông tin vị trí và trạng
thái

7 Terminal capabilities

SCF nhận thông tin về khả năng
của thiết bị người dùng cuối

8 Data session control SCF để điều khiển phiên dữ liệu
9 Generic Messaging SCF để truy nhập vào hòm thư
Không nằm trong
3GPP Rel.4 OSA
10
Connectivity
Management
SCF về QoS
Không nằm trong
3GPP Rel.4 OSA
11
Account
Management
SCF để truy nhập vào tài khoản
người dùng cuối

12
Content based
Charging
SCF để tính cước người dùng
cuối

Vai trò của khung Framework Parlay/OSA
8

Khung Parlay/OSA được xây dựng theo ý tưởng từ TINA và cung cấp truy nhập
được điều khiển tới SCF, được kết hợp với công nghệ phân phối hỗ trợ mềm dẻo ứng dụng
về vị trí và kịch bản thương mại. Hơn nữa, khung framework cho phép nhiều nhà phân phối
thiết bị và thậm chí các SCF không được chuẩn hóa, đây chính là điểm mới chủ yếu và khác
biệt về dịch vụ.
Khung framework Parlay/OSA bao gồm các giao diện với phần lõi gồm:
Ø Quản lý tin cậy và bảo mật: xác thực vùng miền.
Ø Đăng ký SCF: đăng ký SCF mới với khung framework.
Ø Xưởng SCF: tạo SCF mới ngay lập tức.
Ø Khám phá SCF: khám phá các SCF được cung cấp bởi nhà vận hành.
Và cũng có các giao diện khung framework cho:
Ø Quản lý toàn vẹn: cân bằng tải, quản lý lỗi, heartbeat.
Ø Cảnh bảo sự kiện: cảnh báo cho các sự kiện nhất định (đăng ký mới SCS).
Ø Quản lý hợp đồng: quản lý các thỏa thuận giữa các vùng miền (ví dụ: giữa nhà
cung cấp dịch vụ và nhà vận hành)
Để hiểu rõ phần lõi của khung framework thì tốt hơn hết là nhìn vào toàn bộ qui trình
kinh doanh mà một SCS mới được cài đặt và một ứng dụng bắt đầu sử dụng các khả năng
được cung cấp bởi SCS này. Kịch bản được phác thảo trong hình vẽ 2.6. Giả sử rằng SCS
thực hiện SCF điều khiền cuộc gọi đa nhóm. Ta có thể chia thành ba giai đoạn là:
1. Đăng ký
Trong phần này một SCF mới được thêm vào.

Đầu tiên SCS liên lạc với khung framework và yêu cầu giao diện đăng ký của nó.
Khung framework sau đó sẽ trả lại một tham chiếu tới nó. Chúng là bước 1-2 trong hình vẽ.
Tiếp theo SCS điều khiển cuộc gọi đa nhóm sử dụng giao diện này để xuất bản loại SCF của
nó, trong trường hợp này là điều khiển cuộc gọi đa nhóm và khả năng của nó, ví dụ bao
nhiêu nhóm mỗi cuộc gọi mà phương pháp này có thể xử lý. SCS sẽ cung cấp cho khung
framework với tham chiếu của riêng nó (gọi là xưởng dịch vụ) thông qua giao diện đăng ký.
Đây là bước 3 trong hình vẽ. Tại thời điểm này khung framework và SCS đã biết lẫn nhau.
2. Thiết lập thỏa thuận dịch vụ
9

Trong phần này các điều kiện mà một ứng dụng được cho phép để sử dụng SCS được
thiết lập.
Từ thời điểm này, điều hành khung framework có thể nhập vào các điều kiện thông
qua đó một ứng dụng được cho phép để sử dụng SCS. Một trong những điều kiện này là ứng
dụng X chỉ được cho phép sử dụng tối đa 4 nhóm mỗi cuộc gọi. Tất cả các thông tin này
được lưu giữ trong thỏa thuận dịch vụ và thông tin được nhập vào thông qua hệ thống quản
lý.
3. Thiết lập kết nối run-time
Trong giai đoạn này kết nối run-time giữa ứng dụng và SCS được thiết lập.
Bước cuối cùng xảy ra khi một ứng dụng liên lạc với khung framework và sử dụng
giao diện khám phá để tìm ra SCF nào được hỗ trợ (bước 4-6). Giả sử rằng ứng dụng muốn
sử dụng SCF điều khiển cuộc gọi đa nhóm và nó muốn điều khiển cuộc gọi với tối đa 4
nhóm mỗi cuộc gọi. Ứng dụng sẽ hỏi khung framework thông qua giao diện khám phá trả
về tất cả các SCF thực thi mà đáp ứng yêu cầu 4 nhóm mỗi cuộc gọi.
Khung sau đó sẽ kiểm tra thỏa thuận dịch vụ để tìm ra ứng dụng có được cho phép để
sử dụng SCF điều khiền cuộc gọi đa nhóm hay không. Nếu là trường hợp này, nó sẽ trả lại
một danh sách các thực thi của điều khiển cuộc gọi đa nhóm mà có thể xử lý được ít nhất 4
nhóm mỗi cuộc gọi. Ví dụ có thể có hai SCS điều khiển cuộc gọi đa nhóm, trong khi một cái
có thể xử lí tới 8 nhóm mỗi cuộc gọi và cái còn lại xử lí 6 nhóm mỗi cuộc gọi. Khi thông tin
về khả năng của SCS được cung cấp tới ứng dụng, nó có thể chọn lựa ra một SCS từ trong

danh sách (bước 7). Trong trường hợp này thì hầu hết là SCS thứ hai sẽ có chi phí thấp hơn
để sử dụng. Tiếp theo, khung framework sẽ yêu cầu SCS xác định tạo ra một SCF được sử
dụng bởi ứng dụng. Khung framework cũng sẽ gửi thông tin về điều kiện mà để ứng dụng
sử dụng SCF này, ví dụ tối đa 4 nhóm được cho phép mỗi cuộc gọi (hình vẽ). SCS sẽ tạo
SCF ngay lập tức và trả về một tham chiếu tới khung framework (bước 9). Khung
framework sẽ trả nó về ứng dụng (bước 10). Từ thời điểm này ứng dụng có thể sử dụng SCF
điều khiển cuộc gọi đa nhóm.
10


Hình 2.6: Đăng ký dịch vụ và khám phá.
2.2.3 Parlay X
Để cung cấp một API đơn giản cho nhà phát triển web, Parlay X API được hình
thành vào năm 2001 để cung cấp sự tóm tắt và khả năng ở mức cao hơn mà Parlay API
không có. Parlay API phục vụ cho các mặt như cố định, di động và mạng gói nhưng không
hỗ trợ SMS. Lập trình trên giao diện Parlay để cung cấp dịch vụ đơn giản như Click-to-Dial
là phức tạp do tương tác của các thành phần khác nhau và giao diện.
Do thực tế rằng Parlay X cung cấp các khả năng nhất định, một vài tiện ích sẽ không
được trung gian qua Parlay gateway và thay vì đó sẽ khả dụng trên lớp tài nguyên. Hình vẽ
2.11 mô tả các điểm chính của Parlay X.

Hình 2.9: Kiến trúc Parlay X.
11

Hình vẽ 2.10 bên dưới chỉ ra ứng dụng Click-to-Dial sử dụng Parlay X. Trong ví dụ
này bản tin MakeCallRequest() được gọi trên Parlay X API ThirdPartyCallWebService, nó
tạo yêu cầu để thiết lập một cuộc gọi thoại giữa hai địa chỉ (người gọi và người được gọi),
nó chỉ ra ứng dụng được cho phép để kết nối chúng. Kết quả của yêu cầu này được trả lại
trong bản tin 5 là MakeCallResponse() trả lại một nhận dạng cuộc gọi cho cuộc gọi được
tạo. Nhận dạng cuộc gọi được sử dụng bởi ứng dụng dịch vụ logic như là một tham số cho

GetCallInformationRequest(). GetCallInformationRequest() sau đó sẽ được gọi để nhận
thông tin về trạng thái cuộc gọi, dó đó ứng dụng cung cấp dịch vụ logic có thể phải gọi nó
nhiều lần trước khi nhận phản hồi cuộc gọi đang trong quá trình. Khi gọi
MakeCallRequest() trên ThirdPartyCallWebService, nó trao đổi thông tin với Parlay
gateway với các bản tin 3-30. Chuỗi bản tin này tương tự bản tin 3-21 trong phần trước.

Hình 2.10: Dịch vụ Click-to-Dial sử dụng Parlay X API.
12

2.2.4 Bảo mật trong phiên làm việc Parlay/OSA
2.3 Các dịch vụ cơ bản dựa trên nền Parlay/OSA API
Trước khi chúng ta đi vào tổng quan làm thể nào để phát triển một ứng dụng
Parlay/OSA, thì điều quan trọng trước tiên chúng ta cần hiểu là loại ứng dụng nào đang
được sử dụng ngày nay. Chú ý rằng hiện nay có nhiều các API mới và các kiểu ứng dụng
khác nhau. Ví dụ về các API này là: chuyển văn bản tới thoại và trạng thái người dùng (tắt
bật máy hoặc bận)…
Một vài ứng dụng có thể tạo sử dụng Parlay/OSA
· Chữ ký email: gọi lại cho tôi, bao gồm một hình ảnh có thể click trong chữ ký
email của bạn cho phép thiết lập cuộc gọi tới bạn.
· Chặn cuộc gọi: tất cả người sử dụng quay số tới bạn phải biết một số pin mật
mã để có thể thiết lập cuộc gọi tới bạn (ví dụ khi bạn đang trong kì nghỉ).
· Danh sách phân phối cho SMS/MMS/thông báo: dựa trên danh sách phân
phối, gửi quảng bán bản tin của bạn với một danh sách các số.
· Lịch nhắc nhở: nhắc nhở bạn vào một thời điểm nào đó bạn đánh dấu.
· Chặn cuộc gọi tới cuối: cho phép thuê bao chặn cuộc gọi tới cuối cùng (mà
không cần biết số của người gọi)
· Cuộc gọi di động khẩn cấp: gọi một số ngắn và kết nối tới mạng GSM gần
nhất trong vùng xung quanh bạn.
· Digi-Pet: chuyển chiếc điện thoại của bạn thành một vật nuôi ảo. Mỗi khi bạn
thực hiện một cuộc gọi thoại là bạn cho nó ăn. Digipet sẽ nói với bạn “cố lên,

gọi một ai đó đi hoặc tôi sẽ chết vì đói mất”. Nếu bạn không quan tâm DigiPet
đang đói, chiếc điện thoại sẽ dở chứng (nó sẽ nhấp nháy và rung liên tục) vì
vậy bạn sẽ phải cho nó ăn hàng ngày.
· Tin nhắn cuộc gọi lỡ: nhận thông báo hoặc bản tin SMS về tất cả các cuộc gọi
nhỡ.
· Chạy một ứng dụng khi gọi: khi bạn nhận một cuộc gọi sẽ trực tiếp chạy một
ứng dụng với thông tin liên quan dựa trên số thuê bao của người gọi.
· Nhắc nhớ uống thuốc: nhắc nhở bằng SMS/MMS/thông báo khi bạn phải
uống thuốc.
13

· Trò chuyện thoại nặc danh: thiết lập một cuộc gọi từ một phiên chat với một
người mà bạn đang tán gẫu ở trạng thái nặc danh.
· Nhạc chuông và nhạc cá nhân: khi bạn gọi một ai đó, bạn sẽ nghe đoạn nhạc
trong quá trình đổ chuông hoặc bận. Điều này bạn có thể điều chỉnh theo sở
thích của riêng mình.
Trên đây là một số dịch vụ cơ bản dựa trên nền Parlay/OSA API, các dịch vụ này hầu
hết đã có do nhà mạng cung cấp. Tuy nhiên với việc sử dụng Parlay/OSA thì việc phát triển
và triển khai dịch vụ sẽ dễ dàng hơn.
CHƯƠNG 3: KIẾN TẠO DỊCH VỤ TRÊN NỀN PARLAY/OSA
3.1 Kiến tạo dịch vụ dựa trên giao diện mở
3.1.1 Phát triển dịch vụ
3.1.2 Triển khai dịch vụ
3.2 Phát triển và triển khai dịch vụ dựa trên Parlay/OSA API
3.2.1 Các yêu cầu và công cụ cần thiết
a) Yêu cầu hệ thống
Hệ thống sử dụng để phát triển ứng dụng Parlay/OSA chỉ cần là một máy tính với tốc
độ xử lí trên 400MHz. Sử dụng hệ điều hành Linux, Solaris hoặc Microsoft Windows.
Phải được cài đặt các SDK:
ANT ()

Java Mail (
Java Activation Framework (
b) Ngôn ngữ lập trình
Bất kỳ một ngôn ngữ lập trình nào cũng có thể được sử dụng để phát triển ứng dụng
trong Parlay/OSA. Tuy nhiên trong thực tế cho thấy rằng, hầu hết các nhà phát triển đều
thích sử dụng ngôn ngữ Java hơn vì nó có nhiều hàm thư viện và các bộ công cụ hỗ trợ nhà
14

phát triển phần mềm SDK (Sofware Development Kit). Ngôn ngữ Delphi và C++ cũng có
thể được sử dụng để phát triển ứng dụng nhưng khá là hạn chế.
c) Bộ trang bị phát triển phần mềm SDK và các tiện ích
SDK là một bộ các công cụ nền tảng để phát triển ứng dụng của một ngôn ngữ lập
trình. Nó cung cấp cho ta các thư viện, công cụ, tài liệu liên quan để phát triển ứng dụng.
NRG là một máy chủ dịch vụ tiện ích (SCS) cung cấp các dịch vụ như tin nhắn, điều
khiển cuộc gọi, trạng thái người dùng, vị trí người dùng cho ứng dụng. Có hai cách để trao
đổi thông tin với NRG: trực tiếp thông qua giao thức CORBA hoặc thông qua NRG SDK.
Ở đây chúng ta sử dụng các bộ SDK sau:
+ Sun Java SDK: bộ công cụ phát triển phần mềm của ngôn ngữ lập trình Java.
+ Ericsson Network Resource Gateway SDK: bộ công cụ hỗ trợ phát triển ứng dụng
Parlay/OSA của Ericsson. Bằng cách sử dụng NRG nhà phát triển sẽ không cần phải hiểu
biết chi tiết về mạng viễn thông và các kiến thức về CORBA. Các SDK API sẽ làm nhiệm
vụ phiên dịch từ Java sang CORBA và ngược lại Java khi tương tác trong NRG. Điều này sẽ
giúp việc phát triển ứng dụng được tối giản đi rất nhiều
+ Thư viện API
Các API chính của thư viện phần mềm SDK là Core API, Test API và Utility API.
Các SDK cũng đồng thời chứa một vài ví dụ minh họa các ứng dụng NRG sử dụng các dịch
vụ trên NRG như ví dụ về kết nối tới NRG, cách gửi bản tin thông qua SMS và MMS và
cách xử lí định tuyến cuộc gọi…
Core API chịu trách nhiệm cho việc giao tiếp.
Các tiện ích giúp dễ dàng truy nhập tới các dịch vụ H-OSA, quản lí kết nối H-OSA

giữa NRG và ứng dụng được cung cấp bởi Utility API.
Cuối cùng là Test API nó tương đương với Core API, cung cấp giao diện H-OSA
thông qua Java. Tuy nhiên các Test API được sử dụng cho ứng dụng để mô phỏng một
NRG.
d) Bộ mô phỏng
15

Bộ mô phỏng là phần mềm mô phỏng chức năng của một Parlay/OSA gateway và
mạng cơ sở. Các bộ mô phỏng này có thể được cài đặt trên một hệ thống máy tính, do đó
làm cho việc mô phỏng đơn và dễ dàng hơn.
+ Ericsson
+ Appium
3.2.2 Dịch vụ cuộc gọi nhỡ trên phần mềm mô phỏng Parlay/OSA Ericsson
a) Ý tưởng và yêu cầu dịch vụ
Dịch vụ thông báo cuộc gọi nhỡ bằng tin nhắn khi người dùng tắt máy và bật trở lại
sẽ nhận được tin nhắn thông báo có cuộc gọi nhỡ từ một thuê bao khác.
Ứng dụng kết nối tới Framework và yêu cầu dịch vụ trạng thái người dùng (US –
User Status), điều khiển cuộc gọi đa nhóm (MPCC – Multi Party Call Control) và dịch vụ
tin nhắn từ Framework.
Khi nhận được thông báo về trạng thái kích hoạt và xác định rằng người dùng không
thể liên lạc (ở trạng thái tắt máy), ứng dụng sẽ thu thập thông tin về cuộc gọi nhỡ.
Sử dụng dịch vụ MPCC, ứng dụng giám sát sự kiện người dùng cuối kết thúc cuộc
gọi và lưu lại thông tin về người gọi.
Sử dụng dịch vụ tin nhắn, ứng dụng gửi một bản tin SMS với thông tin về cuộc gọi
nhỡ đến người dùng.
Yêu cầu dịch vụ phải gửi được tin nhắn thông báo cuộc gọi nhỡ khi người sử dụng
bật máy trở lại.
b) Phát triển dịch vụ
Mô hình cơ bản của dịch vụ như sau:
16

Hình 3.10: Mô hình các lớp sử dụng trong dịch vụ cơ bản.
Trong đó:
· Main: Khởi tạo, bắt đầu, dừng hoặc hủy dịch vụ.
· Configuration: Cung cấp các dữ liệu liên quan tới cấu hình, định nghĩa các
tham số cho dịch vụ.
· GUI: Cung cấp một giao diện đồ họa đơn giản cho người dùng.
· Feature: Thực hiện các chức năng logic của ứng dụng. Sử dụng FWproxy để
nhận và giải phóng dịch vụ từ NRG được sử dụng bởi các Processors.
· YY_Processor: Tương tác với NRG. Nó sử dụng một dịch vụ quản lí
(IP_XX_Manager) để gửi yêu cầu tới NRG và sử dụng callback adapter
(IpApp_XX_ManagerAdapter) để nhận phản hồi từ NRG.
Ứng dụng dịch vụ này sử dụng các lớp Java sau:
· MPCCProcessor: sử dụng điều khiển cuộc gọi đa nhóm (MPCC) để lấy thông
tin cuộc gọi nhỡ từ một địa chỉ đích xác định.
17

· UserStatusProcessor: sử dụng trạng thái người dùng (US) để lấy thông tin
trạng thái người dùng.
· SMSProcessor: sử dụng Messaging để gửi bản tin SMS.
Các hàm sử dụng trong các class:

Hình 3.11: Các hàm cơ bản sử dụng để phát triển dịch vụ cuộc gọi nhỡ.
Các API sử dụng cho dịch vụ cuộc gọi nhỡ:

Hình 3.12: Các API sử dụng trong dịch vụ cuộc gọi nhỡ.
Từ các hàm như thiết kế và các API liên quan ta sẽ tiến hành lập trình trên ngôn ngữ
Java để tạo ra dịch vụ. Sau khi lập trình xong ta có thể tiến hành chạy thử luôn dịch vụ trên
bộ mô phỏng NRG Ericsson để kiểm thử.

18

Sơ đồ dưới đây là chuỗi các sự kiện xảy ra khi ứng dụng bắt đầu tương tác với khung
framework và yêu cầu báo cáo về trạng thái kích hoạt:
GUI Main Feature MPCCProcessor
UserStatus
Processor
SMS
Processor
FWproxy
start
start
new
obtainSCF
new
new
new
startTriggering
triggeredStatusReportingStartReq
assignmentID1
Application User
IpUserStatus
Bắt đầu chạy
ứng dụng
obtainSCF
obtainSCF

Hình 3.13: Kích hoạt dịch vụ.
Tiếp theo là chuỗi các sự kiện khi ứng dụng nhận báo cáo trạng thái người dùng khi
người dùng không khả dụng:

Hình 3.14: Chuỗi sự kiện khi người dùng không khả dụng.
Tiếp theo là chuỗi các sự kiện khi ứng dụng nhận báo cáo trạng thái người dùng khi
người dùng khả dụng:
19


Hình 3.15: Chuỗi sự kiện khi người dùng khả dụng.
c) Kiểm thử và chạy dịch vụ trên phần mềm mô phỏng
Trong dịch vụ này ta mặc định hai người dùng là “1” và “2”. Khởi chạy dịch vụ, ta
vào Applications rồi chọn Run (hoặc có thể sử dụng phím tắt là Alt+R).
Sau đó, ta chọn Missed Call Messager, rồi click vào nút Run để bắt đầu chạy ứng
dụng.
Quay lại cửa sổ chương trình chính, từ người dùng “1” ta bấm số gọi tới người dùng
“2”. Kết quả người dùng “2” sẽ đổ chuông như hình:
Tiếp theo, ta bấm Cancel để hủy cuộc gọi. Rồi click chuột phải vào người dùng “2”
bỏ chọn “Switched on” để tắt máy người dùng “2”, khi đó thiết bị ngươi dùng “2” sẽ bị mờ
đi.
Bây giờ từ người dùng “1”, ta bấm số để gọi người dùng “2”, cuộc gọi sẽ kết thúc
ngay lập tức. Sau đó, click chuột phải chọn Switched on để bật người dùng “2” lên, ta sẽ
nhận được tin nhắn thông báo cuộc gọi nhỡ từ người dùng “1”.
20


Hình 3.18: Tin nhắn thông báo cuộc gọi nhỡ từ người dùng “1”.
d) Kết luận
3.2.3 Triển khai dịch vụ

KẾT LUẬN VÀ CÁC HƯỚNG NGHIÊN CỨU TIẾP THEO
1. KẾT LUẬN

Xét một cách tổng thể, luận văn đã đề cập đến vấn đề cốt lõi trong xây dựng, phát
triển mạng NGN: phát triển và triển khai dịch vụ. Sự khác biệt lớn nhất của mạng NGN so
với các mạng truyền thống đó là việc phát triển và triển khai dịch vụ nhanh chóng, dễ dàng
và mềm dẻo. Để thực hiện được điều này cần một môi trường kiến tạo dịch vụ mở, tập các
giao diện lập trình ứng dụng API, mô hình phát triển Parlay và các công cụ phát triển hỗ trợ
khác. Trong một chừng mực nào đó, luận văn đã cố gắng trình bày một cách có hệ thống
21

nhất về các vấn đề trên nhưng do điều kiện về thời gian và trình độ có hạn nên không thể
tránh được những thiếu sót nhất định. Các ý kiến đóng góp, bổ sung sẽ được xem xét nghiên
cứu tiếp để làm sáng tỏ các vấn đề liên quan.
2. CÁC Ý KIẾN ĐỀ XUẤT
Trong quá trình tìm hiểu nghiên cứu về môi trường kiến tạo dịch vụ mở, nhận thấy
việc kiến tạo dịch vụ dựa trên giao diện mở và các công cụ hỗ trợ như các hàm thư viện, bộ
phần mềm mô phỏng. Tuy nhiên, nên xây dựng mộ hệ thống các hàm thư viện API với
những ví dụ cụ thể, như vậy sẽ giúp cho các nhà phát triển ứng dụng mới có thể tiếp cận
nhanh hơn.
3. CÁC HƯỚNG NGHIÊN CỨU TIẾP THEO
- Tiếp tục theo dõi, cập nhật các khuyến nghị, đề xuất mới nhất của các tổ chức viễn
thông quốc tế, khu vực như ITU-T, ETSI, 3GPP… về vấn đề phát triển và triển khai dịch
vụ.
- Nghiên cứu tiếp các vấn đề liên quan đến quá trình hội tụ dịch vụ trong giai đoạn
NGN-IMS, ảnh hưởng của nó tới môi trường kiến tạo dịch vụ mở.
- Phát triển hoàn thiện giao diện lập trình ứng dụng API cho quá trình kiến tạo dịch
vụ mở.
- Phát triển hoàn thiện các công cụ phần mềm chuyên dụng để hỗ trợ cho việc phát
triển, quản lý, kinh doanh dịch vụ trong mạng NGN.