GLMS (Group and List Management Server) - umożliwia użytkownikom zarządzanie grupami, listami kontaktów i listami dostępu.

IMS Core - system ten, oprócz zadań związanych z uwierzytelnianiem i autoryzacją abonentów, pełni funkcję "proxy" dla sygnalizacji SIP pomiędzy terminalami użytkowników a serwerem PoC.

Presence server - nieobjęty standaryzacją w PoC rel. 1 - repozytorium informacji o statusie i lokalizacji użytkowników.

Standard PoC rel. 1 definiuje jedynie interfejsy pomiędzy UE a siecią:

Im - pomiędzy UE a GLMS. Poprzez ten interfejs użytkownik zyskuje dostęp do GLMS w celu zarządzania gupami, listami dostępu i listami kontaktów. Używane protokoły to HTTP/XML.

Is - pomiędzy UE a IMS Core. Poprzez ten interfejs odbywa się komunikacja oparta na protokole SIP, używanym do zestawiania/rozłączania sesji przez użytkowników.

It - pomiędzy UE a PoC Server. Tak jak Is jest interfejsem używanym na potrzeby sygnalizacji, tak poprzez It odbywa się transport pakietów zawierających próbki mowy, informacji związanych z floor control i kontrolą jakości połączenia. Używane protokoły to RTP i RTCP.

Pozostałe interfejsy: If, Ik, Ipl, Ips nie zostały określone w obecnym standardzie.

Realizacja PoC w istniejących sieciach GPRS

Należy przypuszczać, że pierwsze komercyjne realizacje będą miały miejsce w już istniejących sieciach 2/2.5 G - nie zaś UMTS.

PoC jest oparta na komunikacji głosowej typu półdupleks, która stawia mniej wymagań odnośnie do wydajności i QoS niż komunikacja dupleksowa. W szczególności półdupleks pozwala na dłuższe opóźnienie w transmisji. Aby jednak pomyślnie wprowadzić usługę PoC, jest niezbędna analiza sieci GPRS w celu identyfikacji ograniczeń (szczególnie wobec faktu, iż gros sieci pracuje obecnie w trybie best effort - bez mechanizmów QoS):

Sieć radiowa - wąskie pasmo dostępne w części radiowej stanowi główne ograniczenie dla wszystkich usług dodanych wykorzystujących IP w sieciach komórkowych 2/2.5 G. W celu zminimalizowania negatywnego wpływu interfejsu radiowego na jakość usługi PoC należy rozważyć:

• wydzielenie kanałów radiowych wyłącznie dla ruchu pakietowego

• ograniczenie liczby użytkowników jednocześnie korzystających z danej komórki/częstotliwości

• priorytetyzację ruchu generowanego przez PoC w stosunku do pozostałego ruchu pakietowego

• zastosowanie kompresji nagłówków UDP/IP zgodnie z RFC 2507

• minimalizację czasu przerwanej transmisji w trakcie przełączania terminala między komórkami (cell reselection), dzięki zastosowaniu nowych mechanizmów w sieci radiowej.

Kodeki głosowe używane w terminalach - w celu ograniczenia wykorzystywanego pasma uzasadniony jest postulat zastosowania jak najbardziej efektywnych kodeków w terminalach. Specyfikacja PoC release 1.0 zaleca stosowanie jako w terminalach domyślnego kodeka AMR 5.15, przy czym terminale powinny obsługiwać również inne przepływności dla AMR. W momencie zestawiania sesji terminale uzgadniają parametry AMR pomiędzy sobą - serwer PoC nie ma funkcji transkodera.

Konteksty PDP i profile QoS:

• Sieć zgodna z 3GPP release 99 udostępnia użytkownikom cztery klasy ruchu (traffic class): conversational, streaming, interactive i background. W przypadku tych sieci jest rekomendowany jeden kontekst PDP na potrzeby sygnalizacji SIP (traffic class - interactive) oraz aktywowanie drugiego kontekstu (secondary) typu streaming do transportu pakietów RTP. Klasa streaming gwarantuje minimalną przepływność - niezbędną do zachowania płynności transferu pakietów mowy.

• Sieci release 97/98 nie udostępniają klasy streaming. W takim przypadku sygnalizacja i transport pakietów RTP współdzielą jeden kontekst PDP albo dwa oddzielne konteksty typu interactive są aktywowane dla sygnalizacji i danych użytkownika.

Przykładowe profile QoS dla użytkowników są zawarte w specyfikacji PoC.

Sieć szkieletowa IP - w celu zmniejszenia opóźnień wprowadzanych przez sieć GPRS należy również rozważyć implementację mechanizmów QoS (na podstawie DiffServ i MPLS) w sieci szkieletowej IP łączącej SGSN-y, GGSN-y i serwery PoC.

Podsumowanie

Mimo że standaryzacja PoC nie została jeszcze w pełni zakończona, to rynek (szczególnie amerykański) czeka na jak najszybsze wdrożenia. Zgodnie z zapowiedziami producentów możemy się spodziewać usługi dostępnej komercyjnie już od połowy 2004 r. - wielu operatorów przeprowadza aktualnie testy próbnych systemów PoC. Równolegle z rozwojem infrastruktury sieciowej powstają terminale - producenci przewidują, że pierwsze telefony wyposażone w funkcję PoC zgodną ze standardem pojawią się na rynku w połowie 2004 r., zaś od 2005 r. PoC stanie się powszechną cechą telefonów.

PoC jest ciekawą usługą z technicznego punktu widzenia, gdyż stanowi pierwszą próbę realizacji VoIP w środowisku bezprzewodowym i krok w stronę komórkowej sieci all-IP. Dzięki półdupleksowej naturze transmisji problem jest uproszczony, niemniej nadal stanowi wyzwanie dla dostawców infrastruktury i operatorów.

Z punktu widzenia końcowego użytkownika PoC tworzy nową jakość (najbliższa analogia to głosowy SMS) i może stanowić podstawę kolejnych usług, np. głosowy czat.

Z dużym prawdopodobieństwem można przyjąć, że głównymi odbiorcami PoC będą organizacje - firmy budowlane, hotele, lotniska, firmy spedycyjne, kurierskie, sprzątające itp., poszukujące tanich środków komunikacji między pracownikami.

Dla operatorów sieci komórkowych PoC stanowi potencjalne źródło zysków - przy założeniu, że będą oni w stanie prawidłowo przewidzieć wpływ PoC na zmniejszenie dochodów z tradycyjnych połączeń głosowych czy telekonferencyjnych i opracować odpowiedni model biznesowy (w szczególności - sposób taryfikacji).

Czy push to talk stanie się długo oczekiwaną killer application w sieciach GPRS? Wkrótce się przekonamy.