(12) Oversettelse av europeisk patentskrift

Transkript

1 (12) Oversettelse av europeisk patentskrift (11) NO/EP B1 (19) NO NORGE (1) Int Cl. H04W 88/06 (09.01) Patentstyret (21) Oversettelse publisert (80) Dato for Den Europeiske Patentmyndighets publisering av det meddelte patentet (86) Europeisk søknadsnr (86) Europeisk innleveringsdag (87) Den europeiske søknadens Publiseringsdato..27 () Prioritet , GB, (84) Utpekte stater AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR (73) Innehaver Sepura PLC, Radio House St. Andrews Road, CambridgeCB4 1GR, GB- Storbritannia (72) Oppfinner RAYNE, Mark, Wentworth, St. James CloseStrethamNr. Ely, Cambridgeshire CB6 3ND, GB-Storbritannia (74) Fullmektig Bryn Aarflot AS, Postboks 449 Sentrum, 04 OSLO, Norge (4) Benevnelse Mobilkommunikasjonssystemer (6) Anførte publikasjoner US-A US-A WO-A-01/17291 "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI); Final draft ETSI EN " ETSI STANDARDS, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. TETRA;TETRA-3, no. V3.2.0, 1 June 07 ( ), XP ISSN:

2 1 Mobilkommunikasjonssystemer 2 3 Foreliggende oppfinnelse vedrører mobilkommunikasjonssystemer, og spesielt mobilkommunikasjonssystemer som kan støtte både kommunikasjon av tale og overføring av pakkedata. Systemet TETRA (TErrestrial Trunked RAdio) er et mobilkommunikasjonssystem som muliggjør kommunikasjon av både tale- og pakkedata. Dokumentet "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI); Final draft ETSI EN " ETSI STANDARDS, LIS, SOPHIA ANTIPOLIS CEDEX, FRANCE, vol. TETRA; TETRA- 3, nr. V3.2.0, 1. juni 07 ( ) er en del av en TETRA-standard. I TETRA finner talekommunikasjon sted over en linjemodus talekanal, og pakkedata blir vanligvis sendt på en "TETRA-pakkedatakanal" (vanligvis på en "styrekanal" som er allokert til overføring av pakkedata). Det blir stadig mer ønskelig for brukere av mobilkommunikasjonssystemer å kunne sende både tale- og pakkedata samtidig. TETRA-systemet tillater dette, men teknikken for dette foreslått i TETRAstandarden er for å la en mobilstasjon sende og motta pakkedata på en TETRApakkedatakanal og sende og motta tale på en linjemodus TETRA-talekanal, uavhengig og kvasisamtidig. Denne løsningen vil derfor normalt kreve at mobilstasjonen har og betjener to uavhengige sett av mottakere og sendere (ett for pakkedataene og ett for talen). Dette øker kompleksiteten til mobilstasjonens oppbygning og er således ikke alltid ønskelig eller mulig. US 03/00602 A1 beskriver et GPRS-kommunikasjonssystem der både sanntidstjenester (f.eks. VoIP) og ikke-sanntidstjenester (f.eks. FTP) tilbys. Det ville også være mulig å sende og motta VoIP-(Voice-over-IP)-pakker på en pakkedatakanal i TETRA, noe som således potensielt kunne gi en alternativ mekanisme for å sende og motta tale og pakkedata samtidig i et TETRA-system. Dette ville imidlertid kreve bruk av en VoIP-KODEK for å kode inn talen i VoIPpakker, noe som i sin tur ville øke mobilstasjonens kompleksitet. I tillegg kunne slik VoIP-tale bare kunne bli mottatt av en annen TETRAmobilstasjon som støtter VoIP, eller dersom VoIP-talen for eksempel ble transkodet til TETRA-kodet tale et annet sted, for eksempel i systeminfrastrukturen. Transkoding av VoIP-talen i systeminfrastrukturen, for eksempel, ville imidlertid ikke være mulig der hvor ende-til-ende-kryptering av talen anvendes (siden ende-til- ende-kryptert tale ved sin definisjon bare bør og kan dekrypteres (og således dekodes) ved sin endedestinasjon).

3 2 2 3 Bruk av VoIP for samtidig overføring av tale- og pakkedata i et TETRA-system er således heller ikke alltid ønskelig eller hensiktsmessig. Søkerne tror derfor at det fortsatt er rom for alternative og forbedrede systemer for å muliggjøre samtidig overføring av tale og pakkedata i TETRAmobilkommunikasjonssystemer. Ifølge foreliggende oppfinnelse tilveiebringes en fremgangsmåte ved kjøring av et TETRA-mobilkommunikasjonssystem ifølge krav 1, og et apparat for bruk i et TETRA-mobilkommunikasjonssystem ifølge krav 8. I utførelsesformer kan fremgangsmåten omfatte å: sende til og/eller motta fra en kommunikasjonsstasjon i systemet, på en TETRA-datapakkekanal, datapakker som inneholder TETRA-kodet tale innsatt mellom datapakker som inneholder andre data for overføring. I utførelsesformer kan apparatet omfatte: en innretning for å sende og/eller motta, på en TETRA-pakkedatakanal, datapakker som inneholder TETRA-kodet tale innsatt mellom datapakker som inneholder andre data for overføring. I utførelsesformer kan fremgangsmåten omfatte: at en kommunikasjonsstasjon sender og/eller mottar, på en TETRApakkedatakanal, datapakker som inneholder TETRA-kodet tale innsatt mellom datapakker som inneholder andre data for overføring. I utførelsesformer kan apparatet omfatte en kommunikasjonsstasjon, omfattende: en innretning for å overføre, på en TETRA-pakkedatakanal, datapakker som inneholder TETRA-kodet tale innsatt mellom datapakker som inneholder andre data for overføring. I foreliggende oppfinnelse blir TETRA-kodet tale sendt ut (eller mottatt) på en TETRA-kanal. Søkerne har spesielt oppdaget at det vil være mulig å kode inn TETRAkodet tale i datapakker som kan bli sendt på en TETRA-kanal, og videre at slike datapakker kan bli satt inn mellom andre (ikke taleinnholdende) datapakker, og med det muliggjøre, i praksis, samtidig overføring av tale og data på (den ene) kanalen. Foreliggende oppfinnelse tilveiebringer således en mekanisme hvorved en kommunikasjonsstasjon i TETRA, så som en mobilstasjon eller basestasjon, kan sende og motta tale og andre data samtidig, men uten behov f.eks. for å ha flere sett av sendere og mottakere og/eller for å anvende andre talekodeker, så som en VoIPkodek. Siden talen fortsatt er TETRA-kodet kan den også mottas av eksisterende og standard TETRA-kommunikasjonsstasjoner, selv om de ikke i seg selv fungerer på måten ifølge foreliggende oppfinnelse.

4 3 2 3 Det vil her forstås at foreliggende oppfinnelse ser for seg og innbefatter slik operasjon både på opplinjen (dvs. fra mobilstasjon til basestasjon (systeminfrastruktur)) og på nedlinjen (dvs. fra basestasjon (systeminfrastruktur) til mobilstasjon) og, ganske visst, og som vil bli beskrevet nærmere nedenfor, i direktemodusoperasjon (dvs. kommunikasjon direkte fra mobilstasjon til mobilstasjon). Der hvor talen blir sendt fra en mobilstasjon (f.eks. for opplinjeoverføring og direktemodusoverføring) vil det være mobilstasjonen selv som formaterer og sender ut talen følgelig, og som således vil innbefatte apparatet ifølge foreliggende oppfinnelse. For overføring fra systeminfrastrukturen til en mobilstasjon (i nedlinjeretning) vil systeminfrastrukturen sørge for å sende talen følgelig og således innbefatte apparatet ifølge foreliggende oppfinnelse. I dette tilfellet kan en basestasjon, eller basestasjonen, selv innbefatte apparatet og utføre denne operasjonen, eller det kan være et passende apparat eller en komponent som er en del av systeminfrastrukturen (f.eks. en del av en SwMI (Switching and Management Infrastructure)) som gjør dette og deretter leverer de relevante dataene til en basestasjon for overføring (og styrer basestasjonen følgelig). Tilsvarende kan TETRA-kanalen på hvilken tale-datapakkene og andre data blir overført være en hvilken som helst passende og ønsket slik kanal, dvs. en kanal som er i stand til å transportere data i denne formen (datapakker). Således kan den være, og vil typisk være, en TETRA-pakkedatakanal, men den kan også være en såkalt "linjemodus" eller annen form for TETRA-kanal dersom denne kanalen er i stand til å transportere pakkedata på behørig måte (som kan være tilfelle i noen "linjemodus" kanalanordninger i TETRA), om ønsket. I en spesielt foretrukket utførelsesform er kanalen en pakkedatakanal. Den TETRA-kodede talen som sendes i datapakker i foreliggende oppfinnelse kan være innkodet ved anvendelse av en hvilken som helst ønsket, definert og støttet talekodek i TETRA. Den er fortrinnsvis kodet ved anvendelse av en fullhastighets TETRA-kodek spesifisert i TETRA-standarden (i EN , del 4). Andre TETRAkodeker, så som AMR-talekodeken definert i punkt 9 i EN , kan bli anvendt om det er ønsket. I en foretrukket utførelsesform blir kodektypen som er anvendt for å kode talen angitt til mottakeren. Teknikker for å gjøre dette vil bli beskrevet nærmere nedenfor. Talen kan bli ende-til-ende-kryptert, for eksempel, og fortrinnsvis, ved anvendelse av kjente TETRA-teknikker for ende-til-ende-kryptering, om ønsket. Datapakkene som den innkodede talen sendes i kan omfatte en hvilken som helst ønsket og passende type datapakke som kan bli overført på en kanal, f.eks.

5 4 2 3 pakkedatakanal, i TETRA. I en foretrukket utførelsesform blir den innkodede talen hensiktsmessig pakket inn i en passende TETRA-protokolldataenhet (PDU - Protocol Data Unit) for overføring. Talen blir fortrinnsvis ikke sendt i en IP-pakke (anvender ikke IP-pakker), og anvender fortrinnsvis ikke topptekster i IP-pakker eller en overføringsprotokoll for IP-datapakker. I en spesielt foretrukket utførelsesform blir den innkodede talen pakket i TETRA N-PDU-datapakker (dvs. datapakker fra applikasjoner som ankommer ved TETRAs SNDCP-(Sub-Network Convergence Protocol)-lag. Mest foretrukket blir hver slik N-PDU deretter pakket inn i en SN-DATA-protokolldataenhet eller en SN-UNITDATAprotokolldataenhet på SNDCP-laget (og så sendt til de lavere lag for videresending, som er kjent i TETRA). I en spesielt foretrukket utførelsesform blir således den TETRAkodede talen sendt i SN-DATA- eller SN-UNITDATA-protokolldataenheter over, f.eks., pakkedatakanalen. Mest foretrukket anvendes SN-UNITDATA-protokolldataenheter for talen, siden disse ikke blir kvittert for og således er bedre egnet for overføringer så som tale hvor rettidig levering kan være viktigere enn pålitelig levering av alle pakker. I en foretrukket utførelsesform inneholder hver tale-datapakke to innkodede TETRA-talerammer, selv om andre løsninger selvfølgelig vil være mulig. I en foretrukket utførelsesform inkluderer datapakkene (f.eks. N-PDU'ene) som inneholder den innkodede talen noen ytterligere data, fortrinnsvis som en topptekst og/eller bunntekst, i tillegg til den innkodede talen. I én foretrukket utførelsesform kan og vil fortrinnsvis en, og i en foretrukket utførelsesform hver enkelt, tale-datapakke inkludere data som angir hvilken talekodek som har blitt anvendt for å kode inn talen og/eller størrelsen til talerammen(e) i datapakkene. Dette har den fordel at dekodingen av tale-datapakken kan være mer direkte, siden den f.eks. ikke trenger å basere seg på annen talekodek- eller rammestørrelsesinformasjon tidligere utvekslet eller avtalt mellom sender og mottaker. Det vil være mulig å bare innlemme eller angi denne informasjonen når kodeken som anvendes endrer seg, om ønsket (og/eller ikke i hver eneste taledatapakke, for eksempel). I en foretrukket utførelsesform inkluderer datapakkene informasjon som angir utsendingsrekkefølgen for talerammen eller -rammene de inneholder (for deres respektive taleramme eller -rammer). Denne er fortrinnsvis i form av et sekvensnummer som angir nummeret innenfor en sekvens av talerammer (eller av par av talerammer) til de aktuelle talerammene (eller parene av talerammer). Dette er for å la mottakeren bestemme talerammenes rekkefølge, og, f.eks., med det dekode dem i korrekt rekkefølge, f.eks. ved leveringsperturbasjoner, og/eller identifisere manglende talerammer, f.eks. forårsaket av mislykkede overføringer etc. (Dette siste

6 2 3 kan være spesielt viktig ved ende-til-ende-kryptering, siden krypteringssynkroniseringen av en taleramme i ende-til-ende-kryptering i TETRA er avhengig av dens utsendingsrekkefølge.) I en foretrukket utførelsesform angis talerammenes rekkefølge ved å innlemme gjeldende verdi for en inkrementeringsteller som teller de suksessive talerammene, parene av talerammer og/eller tale-datapakker. I en foretrukket utførelsesform blir hvert par av talerammer nummerert. Fortrinnsvis anvendes en 6- til 8-bits, fortrinnsvis en 8-bits, teller, ettersom dette skulle tillate mange nok sekvensnummere (tellerverdier) for talerammer eller talerammepar etc. mellom suksessive nye synkroniseringsverdioverføringer (f.eks. for sen inngang) som gjøres i TETRA. Telleren tillates fortrinnsvis å sirkulere rundt hele sitt verdiområde (dvs. blir inkrementert fra sin maksimumsverdi tilbake til null, osv.) siden dette fjerner behovet for å tillate veldig store tellerverdier (og skulle være mulig ettersom det er usannsynlig at en talepakke ankommer så sent at den feilaktig blir tatt for å være en talepakke tilhørende en senere syklus for telleren). I en foretrukket utførelsesform innlemmer tale-datapakkene én eller flere stjålet-markører (stealing marker) (f.eks. svarende til antallet talerammer i datapakkene), som kan bli anvendt for å angi om taledataene (-rammene) i datapakkene har blitt stjålet til andre formål, for eksempel til krypteringssynkronisering eller signalering mellom kodeker. Likeledes kan en eller hver enkelt taleramme i en tale-datapakke fortrinnsvis stjeles til andre formål, for eksempel til krypteringssynkronisering eller signalering mellom kodeker. (Slik synkroniseringssignalering etc. kan selvfølgelig også bli sendt på annen måte, for eksempel i "synkroniseringspakker", i tillegg til eller i stedet for å "stjele" talerammer, om ønsket.) I en foretrukket utførelsesform innlemmer hver tale-datapakke et flagg som angir om talen er ende-til-ende-kryptert eller ikke. Det vil forstås at det kan være behov for en mekanisme hvorved senderen og/eller mottakeren kan angi at den ønsker og/eller bli beordret til å sende og/eller motta tale på måten ifølge foreliggende oppfinnelse. Dette gjøres ved å opprette (påkalle eller aktivere) en bestemt TETRA PDP-(pakkedataprotokoll)-kontekst for å anvende en bestemt protokoll som (tidligere) har blitt definert å angi slik taleoverføring. Som er kjent i TETRA, før en mobilstasjon kan begynne å sende og motta pakkedata via SNDCP-laget, må SNDCP-laget opprette én eller flere PDP-kontekster gjennom forhandling med SwMI'en (Switching and Management Infrastructure) i kommunikasjonssystemet. Denne "forhandlingen" inkluderer å be om at en gitt NSAPI

7 6 2 3 (Network Services Access Point Identifier) blir anvendt som en etikett for PDPkonteksten (i TETRA kan NSAPI'en ha en verdi i området 1 til 14) og avtale protokollen som skal anvendes for datapakkene som sendes ved anvendelse av konteksten. Denne "forhandlingen" kan også inkludere å avtale QoS-(Quality of Service)-parametere for PDP-konteksten. Søkerne har oppdaget at bruk av taleoverføring på måten ifølge foreliggende oppfinnelse hensiktsmessig kan angis ved å anvende protokolltypen som avtales under en PDP-kontekstforhandling for å angi dette. I foreliggende oppfinnelse finnes det således en PDP-kontekstprotokoll som er definert å angi pakkedataoverføring som inneholder tale på måten ifølge foreliggende oppfinnelse, slik at denne protokollen således kan forespørres via forhandling av TETRA PDP-kontekst for å uttrykke et ønske om å anvende slik overføring. Når den er avtalt, vil overføringene som angir den spesifikke, forhandlede, PDP-konteksten la SwMI'en og/eller terminalen (f.eks. en mobilstasjon) gjenkjenne overføring av pakkedata-talerammene på denne måten (på grunn av PDP-konteksten angitt i overføringen) og behandle dem følgelig. I en spesielt foretrukket utførelsesform innbefatter foreliggende oppfinnelse en innretning for eller et trinn med å angi, via en NSAPI-forhandling, den tiltenkte eller ønskede overføringen av TETRA-kodede talerammer i datapakker på en TETRA-kanal, f.eks. en pakkedatakanal. Dette gjøres ved å angi (be om) en bestemt, forhåndsdefinert PDP-kontekstprotokolltype, tidligere definert å angi slik overføring, når PDP-konteksten opprettes. En TETRA-pakkedataprotokoll-(PDP)-kontekst kan således bli opprettet for det formål å overføre TETRA-kodet tale i datapakker. Tilsvarende kan og vil fortrinnsvis toppteksten i hver tale-datapakke (f.eks. og fortrinnsvis SN-UNITDATA PDU) inneholde en NSAPI som angir denne PDP-konteksten. I tillegg til TETRA-systemet som anvender et SNDCP-lag og PDP-kontekster for overføring av pakkedata, kan en rekke andre kommunikasjonssystemer, så som GPRS (GSM), UMTS, 3GPP, WiMax og enkelte satellittkommunikasjonssystemer, anvende og støtte bruk av et SNDCP-lag (eller et ekvivalent lag) og en PDP-kontekst (eller en ekvivalent) for overføring av pakkedata. Bruk av en bestemt PDP-kontekst for overføring av tale på en kommunikasjonskanal, for eksempel, og fortrinnsvis, en pakkedatakanal, ved anvendelse av en spesialdefinert PDPkontekstpakkedataprotokoll i stedet for, for eksempel, å legge inn talen i en IP-pakke, vil være like mulig for, og kan være like fordelaktig i, slike andre systemer som støtter bruk av et SNDCP-lag og PDP-kontekster (eller ekvivalente anordninger) for overføring av pakkedata, som i et TETRA-system.

8 7 2 3 I utførelsesformer kan fremgangsmåten omfatte: overføring av tale i datapakker på en pakkedatakanal ved anvendelse av den opprettede pakkedataprotokollkonteksten, fortrinnsvis sammen med overføring av andre pakkedata over pakkedatakanalen. I utførelsesformer kan apparatet omfatte et kommunikasjonssystem og/eller en kommunikasjonsstasjon omfattende: en innretning for å overføre tale i datapakker på en pakkedatakanal ved anvendelse av den opprettede pakkedataprotokollkonteksten, fortrinnsvis sammen med overføring av andre pakkedata på pakkedatakanalen. Som vil forstås av fagmannen kan og vil fortrinnsvis disse utførelsesformene av foreliggende oppfinnelse inkludere hvilke som helst ett eller flere av eller alle de foretrukne og valgfrie trekkene ved foreliggende oppfinnelse beskrevet her, avhengig av hva som finnes passende. For eksempel blir talen i datapakkene fortrinnsvis kodet inn ved anvendelse av en passende talekodek i det aktuelle kommunikasjonssystemet (for eksempel en TETRA-kodek). Tilsvarende blir den innkodede talen fortrinnsvis overført ved å sende kodek-talerammer inne i passende datapakker (f.eks. protokolldataenheter) i stedet for at de legges inn i en IP-pakke, og uten bruk av en IP-pakke-topptekst. Det er også foretrukket, som angitt over, å også overføre andre data sammen med taledataene. Disse andre dataene kan, og vil ganske visst fortrinnsvis, anvende sin egen protokoll og PDP-kontekst etc., avhengig av sin karakter, så som bruk av en tidligere opprettet IP-(Internet Protocol)-PDP-kontekst dersom de andre dataene er i form av IP-datapakker. (Med andre ord vil talepakkene bli overført ved anvendelse av den pakkedataprotokollen og pakkedataprotokollkonteksten som tidligere har blitt definert og opprettet for dette formålet, mens de andre dataene ikke trenger, og fortrinnsvis ikke vil, bli overført ved anvendelse av denne protokollen og konteksten, men vil bli overført ved anvendelse av egen, hensiktsmessig og forskjellig, protokoll og kontekst.) I disse utførelsesformene av oppfinnelsen kan PDP-konteksten bli opprettet f.eks. mellom en terminal og SwMI'en (infrastrukturen) i kommunikasjonssystemet, mellom en terminal og en annen terminal, mellom en terminal og en (direktemodusdrevet) gateway etc., avhengig av hva som er hensiktsmessig og ønsket. I disse utførelsesformene av oppfinnelsen fremsettes forespørselen om å anvende den bestemte PDP-konteksten definert for taleformål fortrinnsvis ved å sende en passende aktiveringsprotokolldataenhet (for eksempel en TETRA SN-ACTIVATE PDP CONTEXT DEMAND-protokolldataenhet) som angir dette. Fortrinnsvis blir et gitt ATID-

9 8 2 3 (Address Type Identifier in Demand)-element (som angir protokolltypen som forespørres) anvendt i (SN-ACTIVATE PDP CONTEXT DEMAND)-protokolldataenheten for å angi at forespørselen vedrører overføring av tale-pakkedata på måten ifølge foreliggende oppfinnelse. Fortrinnsvis er således en verdi for ATID-elementet som angir slik overføring av tale-pakkedata definert. I en foretrukket utførelsesform kan forhandlingen som oppretter den aktuelle taleoverføringskonteksten etc. også bli anvendt for å angi typen talekodek (og/eller talerammestørrelsen) som anvendes. Denne angis fortrinnsvis av et passende element (felt) i protokolldataenheten SN-ACTIVATE PDP CONTEXT DEMAND. Dette kan unngå behovet for å innlemme slike data i selve tale-datapakkene. Som nevnt over kan kanalen, f.eks. en pakkedatakanal, som de taleinneholdende datapakkene blir overført på være en hvilken som helst passende slik kanal (f.eks. som har kapasitet til å transportere tale-datapakkene). I én foretrukket utførelsesform er det en flerluke pakkedatakanal (dvs. en pakkedatakanal som anvender flere tidsluker). Kanalen, f.eks. en pakkedatakanal, kan anvende et hvilket som helst passende og ønsket moduleringsskjema i eller for det aktuelle kommunikasjonssystemet. Den kan, for eksempel, anvende et moduleringsskjema med høyere datahastighet, så som og fortrinnsvis, i TETRA, moduleringsskjemaene foreslått for høyhastighets pakkedatatjenester i TETRA (TEDS - TETRA Enhanced Data Services). I en foretrukket utførelsesform blir tale-datapakkene overført ved anvendelse av en moduleringsmetode som det anses som mer trolig at blir pålitelig mottatt, for eksempel i betraktning av de foreliggende kanalforholdene. For et TETRA-system kan derfor en 4-QAM R = 1/2-kanal være foretrukket fremfor en 16-QAM R = 1/2-kanal, som igjen kan være foretrukket fremfor en 64-QAM R = 2/3-kanal. I alminnelighet kan således relativt lavere-nivå moduleringsmetoder være foretrukne, siden de innlemmer færre databit per moduleringssymbol og således tildeler mer energi per bit, og derfor kan være mer pålitelige. På den annen side kan en høyere moduleringsrate overføre flere bit per sekund, dersom forholdene tillater det. I en foretrukket utførelsesform blir derfor tale-datapakkene overført med et lavt (relativt lavere) moduleringsnivå for å øke sannsynligheten for vellykket levering. Det vil også være mulig f.eks. å anvende linktilpasning for taleoverføringen om ønsket, så som, for eksempel, under gode kanalforhold å skifte overføringen opp til et høyere moduleringsnivå det antas vil fungere tilfredsstillende pålitelig (basert f.eks. på en vurdering av kanalytelsen fra signaleringsmeldinger eller feedbackmeldinger i motsatt retning).

10 9 2 3 De andre dataene som overføres sammen med tale-datapakkene på kanalen, f.eks. en pakkedatakanal, kan omfatte hvilke som helst ønskede og passende slike data. De kan være andre taledata (dette kan være hensiktsmessig for kringkastede taleanrop). I en foretrukket utførelsesform er disse ikke-taledata og er fortrinnsvis brukerdata (brukertrafikk) (i motsetning til systemsignaleringsdata, for eksempel). I en foretrukket utførelsesform blir de andre dataene overført som IP-(Internet Protocol)-datapakker. I en foretrukket utførelsesform kan kommunikasjonsstasjonen fortrinnsvis sende, og lagrer fortrinnsvis for overføring, sammen med tale-datapakkene, data som den ønsker å sende med et lavt eller pålitelig moduleringsnivå (siden, som nevnt over, det kan være foretrukket at de tale-inneholdende datapakkene blir sendt med bruk av et lavt og/eller pålitelig moduleringsnivå). Tale-datapakkene og de andre datapakkene kan bli overført sammen på kanalen, f.eks. en pakkedatakanal, som ønsket. For eksempel, og fortrinnsvis, blir datapakkene som ikke inneholder tale fortrinnsvis innsatt innenfor sekvensen av taledatapakker som overføres etter hvert som og når det er plass til dem i kanalen. I en foretrukket utførelsesform blir både en tale-datapakke og en datapakke som inneholder andre data overført innenfor én enkelt overføringstidsluke (og fortrinnsvis innenfor hver overføringsluke mens talen blir overført). Overføringen av de andre datapakkene, f.eks. datapakker som ikke inneholder tale, er fortrinnsvis underlagt eventuelle begrensninger som følge av behovet for å sende tale-datapakkene på riktig måte, så som båndbreddebegrensninger som følge av taleoverføringen og/eller kommunikasjonsstasjonens behov for å skifte mellom mottak og utsending for å opprettholde samtalen, og/eller behovet for å sende talerammene med jevne mellomrom og for å finne plass til de andre dataene rundt disse. I en spesielt foretrukket utførelsesform blir talen sendt som sanntidsklassedata (som støttes av TETRA). De andre pakkedataene, dersom de ikke er tale, blir tilsvarende fortrinnsvis sendt som bakgrunnsklasse-data (som støttes av TETRA). Mest foretrukket blir hver taleramme kun sendt én gang. Tale-datapakkene blir fortrinnsvis sendt ved anvendelse av en regelmessig overføringsplan. Når det ønskes å gjøre et taleanrop ved anvendelse av teknikken ifølge foreliggende oppfinnelse, kan en hvilken som helst passende anropsstyringsprotokoll bli anvendt for anropet. I en foretrukket utførelsesform anvendes den eksisterende anropsstyringsprotokollen i TETRA, underlagt eventuelle tilpasninger nødvendig for å la minst én deltaker sende eller motta talen via f.eks. en pakkedatakanal (eller en annen passende kanal) på måten ifølge foreliggende oppfinnelse.

11 2 3 I en foretrukket utførelsesform kan en samtaledeltaker spesifikt be om et pakkedata-taleanrop når den forespør eller mottar et taleanrop, f.eks., og fortrinnsvis, ved å anvende passende, f.eks. forhåndsdefinert, anropsstyringssignalering. Tilsvarende kan en kommunikasjonsstasjon som ønsker å begynne å sende eller motta andre pakkedata under et linjemodus taleanrop fortrinnsvis beordre endring til et pakkemodus taleanrop, f.eks. ved å anvende en passende, fortrinnsvis forhåndsdefinert, anropsstyringsmelding. I en foretrukket utførelsesform kan kommunikasjonssystemets infrastruktur, fortrinnsvis SwMI'en, observere at én deltaker i en påtenkt samtale holder på med å sende eller motta pakkedata og støtter pakkedata-taleanrop, og tilordne denne deltakeren til et pakkedata-taleanrop følgelig. Mest foretrukket kan infrastrukturen (SwMI'en) også eller i stedet, fortrinnsvis også, automatisk endre anropet til pakkemodusoperasjon for en kommunikasjonsstasjon (f.eks. og fortrinnsvis ved anvendelse av en passende anropsstyringsmelding) når den oppdager en forespørsel om å begynne å sende eller motta pakkedata fra kommunikasjonsstasjonen på et tidspunkt kommunikasjonsstasjonen tar del i et linjemodus taleanrop. Tilsvarende, når en kommunikasjonsstasjon som tar del i et pakkemodus taleanrop slutter å sende eller motta andre pakkedata, kan kommunikasjonsstasjonen fortrinnsvis be om å bli tilbakeført til et linjemodus anrop, og/eller infrastrukturen (SwMI'en) kan detektere avbrytelse av de andre pakkedataene (f.eks., i TETRA, ved utløp av alle andre SNDCP CONTEXT_ READY-timere) og automatisk tilbakeføre kommunikasjonsstasjonen til linjemodus tale. I en foretrukket utførelsesform kan kommunikasjonssystemets infrastruktur (SwMI'en) velge å omkoble kommunikasjonsstasjoner mellom linjemodus tale og pakkemodus tale for å lette forvaltning av de tilgjengelige radioressursene (f.eks. dersom SwMI'en går tom for linjemodus-trafikkanaler). I en foretrukket utførelsesform, når en mobilstasjon (MS) flyttes fra en celle som støtter linjemodus taleanrop til en celle som ikke støtter linjemodus taleanrop mens den tar del i et anrop, gjør kommunikasjonssystemets infrastruktur (SwMI'en) om anropet til et pakkemodus taleanrop. Tilsvarende, når en mobilstasjon flyttes fra en celle som ikke støtter linjemodus taleanrop til en celle som støtter linjemodus taleanrop mens den tar del i et pakkemodus taleanrop, kan kommunikasjonssystemets infrastruktur (SwMI'en) fortrinnsvis gjøre om anropet fra et pakkemodus taleanrop til et linjemodus taleanrop. Foreliggende oppfinnelse kan anvendes med både individuelle samtaler og gruppesamtaler. Ved gruppesamtaler er det fortrinnsvis mulig at noen deltakere kjører

12 i linjemodus på én eller flere delte trafikkanaler og at andre deltakere kjører i pakkemodus på én eller flere delte pakkedatakanaler (PDCH'er). Det er således heller ikke nødvendig at alle deltakere i en samtale anvender pakkedata-taleløsningen ifølge foreliggende oppfinnelse. For eksempel kan én terminal ha en "normal" linjemodus taleforbindelse til infrastrukturen, mens den andre terminalen (eller én annen terminal) er koblet til infrastrukturen via en pakkedata "talekanal" på måten ifølge foreliggende oppfinnelse. Det vil forstås at systeminfrastrukturen i systemet ifølge foreliggende oppfinnelse vil fungere følgelig for å lette kommunikasjon på måten ifølge foreliggende oppfinnelse. Dersom for eksempel en mobilstasjon (MS) sender talerammer til en annen TETRA-MS som anvender pakkedata og støtter mottak av tale på denne måten, videresender således SwMI'en fortrinnsvis talerammene i SN-DATA- eller SN- UNITDATA-PDU'er på nedlinjen til mottaker-mobilstasjonen. Mottaker-mobilstasjonen vil gjenkjenne at disse PDU'ene inneholder talerammer fra sin nedtegnelse av protokollen avtalt for NSAPI'en innlemmet i PDU'en, og vil videresende de ubehandlede talerammene til sin talekodek (via sin ende-til-ende-dekrypteringsenhet dersom ende-til-ende-kryptering er i bruk). Tilsvarende, når en mobilstasjon, for eksempel, sender talerammer som pakkedata til en TETRA-mobilstasjon som ikke anvender pakkedata, eller som ikke støtter levering av tale i dette formatet, tildeler SwMI'en fortrinnsvis den destinerte mobilstasjonen en linjemodus talekanal, trekker ut de ubehandlede talerammene fra SN-DATA- eller SN-UNITDATA-protokolldataenhetene sendt av avsendermobilstasjonen, anvender den normale TETRA tale-(tch/s)-kanalkodingen og - innfellingen og leverer talerammene til mottaker-mobilstasjonen i rekkefølge i suksessive trafikkanalluker på normal måte for et linjemodus taleanrop. I dette tilfellet, hvor mottakeren nås via en linjemoduskanal, sikrer SwMI'en fortrinnsvis at talerammene blir sendt i korrekt rekkefølge (f.eks. ved å anvende begrenset bufring), erstatter manglende talerammer med nuller eller tilfeldige talerammer og forkaster sene pakker. (Den store størrelsen til rammeparnummertelleren vil bidra til å sikre at sene pakker alltid kan forkastes når ende-til-endekryptering anvendes.) Når derimot SwMI'en mottar tale fra en mobilstasjon (for eksempel) som anvender en normal TETRA-trafikkanal og ønsker å sende talen til en mobilstasjon som på det aktuelle tidspunktet anvender en passende pakkedatakanal og støtter fremgangsmåten ifølge denne oppfinnelsen, fjerner SwMI'en fortrinnsvis innfellingen og kanalkodingen fra talerammene på opplinjen og sender dem til mottaker-

13 mobilstasjonen inne i SN-DATA- eller SN-UNITDATA-PDU'er på den pakkedatakanalen (PDCH'en) som anvendes av mottakeren. Kommunikasjonsstasjonen i foreliggende oppfinnelse kan være en hvilken som helst passende slik stasjon eller kommunikasjonsterminal, så som en mobilstasjon eller en basestasjon. Den kan også være en passende stasjonær (TETRA-) terminal, så som en tidsklareringsterminal. Foreliggende oppfinnelse kan også anvendes med direktemodus-kjørende kommunikasjonsterminaler og med direktemodusoperasjon. For eksempel kan en direktemodus-gateway i TETRA gjøre om et linjemodus DMO-taleanrop til pakkedatatale for tilkobling inn i V+D-systemet, og omvendt. Tilsvarende kan en pakkedata DMO-terminal sende pakkedata-tale gjennom en pakkedata-gateway, hvor enten én eller begge av terminalen og gatewayen kan anvende foreliggende oppfinnelse. Som vil forstås fra det ovennevnte kan de forskjellige operasjoner og funksjoner ifølge foreliggende oppfinnelse utføres av og implementeres i en mobilstasjon og/eller i kommunikasjonssystemets systeminfrastruktur, avhengig av hva som er ønsket og hensiktsmessig. For eksempel vil det ved utsending fra en mobilstasjon på måten ifølge foreliggende oppfinnelse være mobilstasjonen som utfører de forskjellige funksjoner og operasjoner ifølge foreliggende oppfinnelse, og innlemmer apparatet ifølge foreliggende oppfinnelse. Tilsvarende vil det ved utsending fra systeminfrastrukturen være systeminfrastrukturen som utfører de forskjellige funksjoner og operasjoner ifølge foreliggende oppfinnelse, og innlemmer apparatet ifølge foreliggende oppfinnelse. I dette sistnevnte tilfellet kan funksjonene etc. bli utført av basestasjonen selv og/eller av en annen komponent i systeminfrastrukturen. De kan også bli utført på en distribuert måte (og apparatet kan være innlemmet på en distribuert måte) i systeminfrastrukturen om ønsket. Foreliggende oppfinnelse innbefatter således også en kommunikasjonsstasjon, så som, fortrinnsvis, en mobilstasjon, eller en basestasjon, som innlemmer apparatet ifølge foreliggende oppfinnelse, samt et TETRA-kommunikasjonssystem som innbefatter apparatet ifølge foreliggende oppfinnelse, fortrinnsvis i sin infrastruktur. Som vil forstås av fagmannen kan og vil fortrinnsvis alle utførelsesformene av oppfinnelsen beskrevet her innlemme hvilke som helst ett eller flere av eller alle de foretrukne og valgfrie trekkene ved oppfinnelsen beskrevet her, etter hva som finnes hensiktsmessig. Fremgangsmåtene ifølge foreliggende oppfinnelse kan bli utført i hvert fall delvis ved hjelp av programvare f.eks. dataprogrammer. Utførelsesformer av

14 foreliggende oppfinnelse kan således omfatte dataprogramvare spesifikt tilpasset for å utføre en fremgangsmåte eller fremgangsmåtene beskrevet her når den er installert på en databehandlingsanordning, et dataprogramelement omfattende dataprogramkodeandeler for å utføre en fremgangsmåte eller fremgangsmåtene beskrevet her når programelementet kjøres på en databehandlingsanordning, og et dataprogram omfattende kodemidler tilpasset for å utføre alle trinnene i en fremgangsmåte eller i fremgangsmåtene beskrevet her når programmet kjøres på et databehandlingssystem. Oppfinnelsen innbefatter også en dataprogramvarebærer omfattende slik programvare som når den anvendes for å operere et TETRA-kommunikasjonssystem omfattende en databehandlingsanordning sammen med nevnte databehandlingsanordning bevirker nevnte system til å utføre trinnene i en fremgangsmåte eller i fremgangsmåtene ifølge foreliggende oppfinnelse. En slik dataprogramvarebærer kan være et fysisk lagringsmedium, så som en ROM-brikke, et CD-ROM eller et platelager, eller kan være et signal så som et elektronisk signal over kabler, et optisk signal eller et radiosignal, for eksempel til en satellitt eller liknende. Det vil videre forstås at ikke alle trinn i fremgangsmåtene ifølge oppfinnelsen trenger bli utført av dataprogramvare, og ytterligere generelle utførelsesformer av foreliggende oppfinnelse omfatter således dataprogramvare og slik programvare installert på en dataprogramvarebærer for å utføre minst ett av trinnene i en fremgangsmåte eller i fremgangsmåtene vist her. Foreliggende oppfinnelse kan derfor tjenlig realiseres som et dataprogram for bruk med et datasystem. En slik realisering kan omfatte en sekvens av datamaskinlesbare instruksjoner enten inneholdt på et håndgripelig medium, så som et datamaskinlesbart medium, for eksempel en diskett, et CD-ROM, et ROM eller en harddisk, eller som kan sendes til et datasystem, via et modem eller en annen grensesnittsanordning, over enten et håndgripelig medium, inkludert, men ikke begrenset til optiske eller analoge kommunikasjonslinjer, eller uhåndgripelig ved anvendelse av trådløse teknikker, inkludert, men ikke begrenset til mikrobølgebaserte, infrarødt-baserte eller andre overføringsteknikker. Sekvensen av datamaskinlesbare instruksjoner innlemmer all eller en del av funksjonaliteten beskrevet over. Fagmannen vil forstå at slike datamaskinlesbare instruksjoner kan være skrevet i en rekke forskjellige programmeringsspråk for bruk med mange datamaskinarkitekturer eller operativsystemer. Videre kan slike instruksjoner bli lagret ved anvendelse av en hvilken som helst minneteknologi, nåværende eller fremtidig, inkludert, men ikke begrenset til halvlederbasert, magnetisk eller optisk, eller overført

15 ved anvendelse av en hvilken som helst kommunikasjonsteknologi, nåværende eller fremtidig, inkludert, men ikke begrenset til optisk, infrarødt-basert eller mikrobølgebasert. Det overveies at et slikt dataprogramprodukt kan bli distribuert som et flyttbart medium med tilhørende trykket eller elektronisk dokumentasjon, for eksempel krympepakket programvare, forhåndslastet med et datasystem, for eksempel på et system-rom eller et stasjonært platelager, eller distribuert fra en tjener eller en elektronisk oppslagstavle over et nettverk, for eksempel Internett, dvs. verdensveven. Et antall foretrukne utførelsesformer av foreliggende oppfinnelse vil nå bli beskrevet, kun som eksempler. TETRA anvender en TDMA-signaleringsstruktur. En linjemodus talekanal i TETRA omfatter 1 tidsluke per ramme (bestående av 4 tidsluker), i hvilken en avsender-mobilstasjon (MS) normalt setter inn to talerammer. TETRA-talerammer kodet med den vanlige TETRA-kodeken inneholder 137 bit med informasjon (EN , punkt ) før kanalkoding. Etter kanalkoding inneholder de 216 bit. Linjemodus tale blir alltid sendt i kanaler med én enkelt luke og båndbredde 2 khz som anvender π/4-dqpsk-modulering. Hver halve luke i en linjemodus TETRA-talekanal (forkortet TCH/S) rommer 216 bit; en full luke inneholder 432 bit. (I praksis, der hvor en luke inneholder to talerammer, blir de to rammene med totalt 274 ubehandlede bits kodet og flettet sammen slik at de utgjør totalt 432 kodede bits.) Ved noen anledninger kan en TETRA-mobilstasjon stjele (dvs. bytte ut) talen i den første halve luken med en signaleringsmelding. Ved andre anledninger kan TETRAs mekanisme for ende-til-ende-kryptering (når talen blir ende-til-ende-kryptert) stjele én av eller begge talerammene og bytte dem ut med krypteringssynkroniseringsinformasjon. Dette kan skje flere ganger i begynnelsen av taleoverføringen for å la mottakeren oppnå innledende synkronisering og deretter periodisk (f.eks. én gang per sekund) for å muliggjøre sen inngang av andre mobilstasjoner som ønsker å motta anropet. Når ende-til-ende kryptering anvendes, siden talerammer ikke er nummerert, må den riktige rekkefølgen til krypterte talerammer i deres gjennomgang gjennom SwMI'en bevares, og eventuelle manglende talerammer merkes, slik at mottakeren korrekt kan beregne krypteringssynkroniseringen anvendt for hver taleramme gjennom forlengelse av synkroniseringen anvendt for den foregående talerammen. TETRA-pakkedata blir sendt på en TETRA-styrekanal. En pakkedatakanal (PDCH) er et spesialtilfelle av en TETRA-reservert styrekanal.

16 Standarden TETRA (EN v3.2.1) tillater bruk av pakkedatakanaler med flere luker. Den tillater også bruk av flere moduleringstyper, dvs. fasemodulering (π/ 4 - DQPSK, og π/8 - D8PSK) og QAM-modulering (f.eks. 4-QAM rate r = ½, 16- QAM r = ½, 64-QAM r = ½, 64-QAM r = 2/3 og 64-QAM r = 1). Fasemodulering anvender alltid kanaler med 2 khz båndbredde, men QAM-modulering kan anvende kanaler med 2 khz, 0 khz, 0 khz og 0 khz båndbredde. Kapasiteten på MAC-(Medium Access Control)-nivå til en PDCH i TETRA avhenger av typen modulering som anvendes, og kanalens RF-båndbredde. Tabell 1 viser antallet MAC-bits tilgjengelig i luker for forskjellige typer kanal, RF-båndbredder, og moduleringstyper (som gir plass til CRC-bits, eventuelle halebits og kanalkoding (disse verdiene kan finnes fra EN ). Tabell 1: MAC-bits tilgjengelig i forskjellige typer TETRA-kanaler. Kanalnavn SCH/F (2 khz) SCH-P8/F (2 khz) SCH-Q/U (2 khz) SCH-Q/U (0 khz) SCH-Q/U (0 khz) SCH-Q/U (0 khz) π/4- π/8-4-qam 16-QAM DQPSK D8PSK r=1/2 r=1/2 64-QAM 64-QAM 64-QAM r=1/2 r = 2/3 r= Når tale sendes over en TETRA-trafikkanal er det ingen ytterligere administrasjonsdata etter kanalkodingen. Pakkedata som sendes over TETRA blir imidlertid sendt i en signaleringskanal innenfor et hierarki av protokolldataenheter (PDU'er), slik at, når TETRAtalekodekrammer sendes på TETRA-pakkedatakanaler (PDCH'er), det også er nødvendig å betrakte administrasjonen i MAC-, LLC-, MLE- og SNDCP-lagenes PDUtopptekster. De tilgjengelige N-PDU-bitene for forskjellige typer pakkedatakanal-luke er vist i tabell 2.

17 16 Tabell 2: N-PDU-bits tilgjengelig per luke i forskjellige typer TETRA-kanaler. Kanalnavn SCH/F (2 khz) SCH-P8/F (2 khz) SCH-Q/U (2 khz) SCH-Q/U (0 khz) SCH-Q/U (0 khz) SCH-Q/U (0 khz) π/4- π/8-4-qam 16-QAM DQPSK D8PSK r=1/2 r=1/2 64-QAM 64-QAM 64-QAM r=1/2 r = 2/3 r= Det kan sees fra dette at to TETRA-talerammer med totalt 274 ubehandlede bits ikke får plass i en 2 khz π/4-dqpsk-kanal eller 4-QAM-kanal som gir én luke per ramme, men d får plass i en hvilken som helst annen type PDCH-kanal, inkludert en π/4-dqpsk PDCH-kanal som anvender to eller flere luker per ramme. Det kan også sees at to TETRA-talerammer med 432 kodede bits får plass i 4- QAM-kanaler som anvender en båndbredde på 0 eller 0 khz. Pakkedatakanaler med flere luker skulle tilsvarende gi nok kapasitet til overføring av tale og data samtidig. Videre er det i alminnelighet mer enn nok plass i kanalen til å innlemme andre datapakker i tillegg til TETRA-talerammene. I TETRA (og GSM- og GPRS-systemer) håndteres pakkedata i SNDCP-(Sub- Network Convergence Protocol)-laget. Datapakker som ankommer til SNDCP-laget i TETRA fra applikasjoner er kjent som N-PDU'er. SNDCP-laget pakker inn hver N-PDU i en SN-DATA-PDU eller en SN- UNITDATA-PDU og sender den til de lavere lagene for videresending. Toppteksten i hver SN-(UNIT)DATA-PDU inneholder en NSAPI, som er en referanse til en PDP- (Packet Data Protocol)-kontekst. PDP-konteksten identifiserer protokollen som anvendes av pakken (og, for IP-protokollen, for eksempel, kilde-ip-adressen i pakker på opplinjen, destinasjons-ip-adressen i pakker på nedlinjen og typene komprimering anvendt (om noen)).

18 17 Før en mobilstasjon (MS) kan begynne å sende og motta pakkedata i TETRA, må SNDCP-laget i mobilstasjonen opprette én eller flere PDP-kontekster ved å forhandle med SwMI'en. Forhandlingen inkluderer å avtale tjenestekvalitets-(qos)- parametere for PDP-konteksten, be om en gitt NSAPI (én av fjorten mulige verdier for TETRA) og avtale en pakkedataprotokoll. Dersom en IP-protokoll forespørres, for eksempel, blir en IP-adresse også avtalt for den forespørrende applikasjonen og IP-adressen bindes til NSAPI'en og mobilstasjonens adresse i SwMI'en. Dette setter SwMI'en i stand til å rute IPadresserte pakker til korrekt MS og korrekt NSAPI innenfor MS'en. MS'en kan så anvende NSAPI'en for å rute pakken til korrekt applikasjon. En foretrukket utførelsesform for å overføring av TETRA-talerammer i datapakker på en TETRA-pakkedatakanal sammen med andre datapakker vil nå bli beskrevet. I den foreliggende utførelsesformen blir TETRA-talerammer overført på pakkedatakanalen som passende N-PDU'er (protokolldataenheter). Tabell illustrerer formatet til en tale-datapakke i TETRA som blir overført i den foreliggende utførelsesformen. Tabell : Innhold i en TETRA-talepakke inneholdt i en SN-DATA-PDU Informasjonselement Lengde Type C/O/M Merknad Flagg for ende-til-endekryptering 1 1 M KODEK-type 8 1 M Talerammepar-nummer 8 1 M Første 1 1 M rammestjelingsflagg Første taleramme Varierer C Se merknad 1 og 2 Første stjålne ramme 137 C Se merknad 3 Andre 1 1 M rammestjelingsflagg Andre taleramme Varierer C Se merknad 4 og Andre stjålne ramme 137 C Se merknad 6 Merknad 1: Skal forefinnes dersom første rammestjelingsflagg = "0" Merknad 2: Lengde avhenger av KODEK-type. Lengden skal være 137 bit dersom KODEK-type = "standard TETRA CODEC". Merknad 3: Skal forefinnes dersom første rammestjelingsflagg = "1" Merknad 4: Skal forefinnes dersom andre rammestjelingsflagg = "0"

19 18 Merknad : Lengde avhenger av KODEK-type. Lengden skal være 137 bit dersom KODEK-type = "standard TETRA CODEC". Merknad 6: Skal forefinnes dersom andre rammestjelingsflagg ="1" 2 Som vist i tabell inkluderer hver tale-datapakke for det første to talerammer. Dersom den standard TETRA-kodeken blir anvendt, vil hver taleramme omfatte 137 bit, som vist. (Dersom en annen TETRA-talekodek blir anvendt, vil antallet bit som anvendes i første og andre taleramme være forskjellig (dvs. vil være noe annet enn 137 bit).) Som vist i tabell, i tillegg til talerammene, innbefatter tale-datapakken også noen andre topptekstdata inne i tale-n-pdu'en. For det første er et datafelt lagt til som angir hvilken talekodek som anvendes. Dette anvendes for å angi størrelsen til hver taleramme (som angitt over vil denne i en standard TETRA-KODEK være 137 bit, men kan være en annen for andre talerammer). Denne informasjonen anvendes av mottakeren av TETRA-talepakker for å dekode PDU'en på korrekt måte. Innlemmelse av kodektypen i hver PDU som inneholder TETRA-taledata gjør at dekodingen av PDU'ene kan være mer direkte, siden denne ikke avhenger av informasjon lagret under PDP-kontekstaktivering. Som en alternativ løsning kan et ett-bits "kodek endret-flagg" innlemmes i taledatapakken og da det 8-bits KODEK-type elementet bare innlemmes når kodek endret-flagget er satt. Tale-datapakken inkluderer også et talerammepar-nummerverdi som angir sekvensnummeret til paret av talerammer i datapakken. Talerammepar-nummeret er innlemmet for å sette SwMI'en og senere mottakere i stand til å holde talepakkene i korrekt rekkefølge, siden datapakker kan følge forskjellige ruter gjennom pakkedatanettverk og således ankomme i feil rekkefølge. Dette gjør at mottakeren kan dekode talerammene i korrekt rekkefølge dersom en leveringsperturbasjon har funnet sted, og kan anvendes for å identifisere manglende talerammer forårsaket av mislykkede overføringer etc. Dette er spesielt viktig når ende-til-ende-kryptering anvendes, siden krypteringssynkroniseringen for hver taleramme er avhengig av dens utsendingsrekkefølge. Mottakeren må derfor ordne innkommende talepakker i riktig rekkefølge og hensynta eventuelle manglende pakker før den forsøker å dekryptere talen. (Dersom mottakeren er nådd via en linjemodus-kanal, må SwMI'en sikre at talerammene blir sendt i korrekt rekkefølge (muligens gjennom begrenset bufring),

20 erstatte manglende talerammer med nuller eller tilfeldige talerammer og forkaste forsinkede pakker.) Talerammepar-nummere genereres i den foreliggende utførelsesformen ved hjelp av en teller. I TETRA blir en ny synkroniseringsverdi sendt omtrent én gang per sekund (dvs. omtrent hvert 18. par av talerammer), slik at en 6- til 8-bits teller i alminnelighet vil være tilstrekkelig. Telleren sirkuleres syklisk gjennom hele sitt verdiområde i den foreliggende utførelsesformen. Dette er mulig siden en talepakke trolig ikke vil ankomme så sent at den feilaktig blir tatt for å være en talepakke som tilhører en senere tellersyklus. Den store størrelsen til rammepar-nummeret bidrar til å sikre at sene pakker alltid kan forkastes når ende-til-ende-kryptering anvendes. (Dette er ønskelig fordi at dersom en pakke kommer bort på sin ferd gjennom pakkedatanettverket, avsenderbasestasjonen, i ende-til-ende-krypteringsløsninger i TETRA, må erstatte den bortkomne pakken med en dummy-pakke når den neste talerammen skal sendes til mottakeren, slik at mottakeren ikke mister tellingen over pakkene og således forblir synkronisert. Dersom imidlertid den bortkomne pakken ankommer (kanskje via en annen rute) til avsender-basestasjonen på et senere tidspunkt, må basestasjonen forkaste den sent ankommede pakken, fordi at dersom den sendte den sene pakken til mobilstasjonen, dette ville forvirre mobilstasjonens krypteringssynkronisering (siden den allerede har blitt gjort opp for av dummy-pakken allerede sendt av basestasjonen).) Som vist innlemmer tale-datapakken også to stjålet-markører i talepakken, den ene for den første talerammen og den andre for den andre talerammen, i paret av talerammer i datapakkene. Dette gjør at mottakeren kan se når talerammer har blitt stjålet, for eksempel for krypteringssynkronisering eller signalering mellom KODEK'er. Det vil også eller i stedet være mulig for eksempel å legge til synkroniseringsinformasjonen i vilkårlige TETRA-talepakker i stedet for å erstatte (stjele) talen. Dette kan være fordelaktig i tilfeller der høyeste talekvalitet er nødvendig, i tilfeller der mer hyppig synkronisering er nødvendig og i tilfeller der kanalen har tilstrekkelig båndbredde slik at den har god plass til både talen og synkroniseringen. (Der hvor slik tale blir sendt videre av SwMI'en til dens destinasjon i en linjemodus-kanal, vil SwMI'en måtte droppe talen når synkroniseringsinformasjon er innlemmet.) Alternativt kan SwMI'en velge mellom å droppe synkroniseringen eller droppe talen for å gi omtrent ett synkroniseringsutbrudd per sekund på en linjemodus talekanal.

21 Størrelsen til en tale-datapakke i TETRA basert på tabell er 293 bit når den standard TETRA-KODEK'en anvendes. Denne vil få plass i alle typer pakkedatakanaler bortsett fra en π/4-dqpsk-kanal med én luke eller når 4-QAM r =1/2-modulering anvendes i en 2 khz kanal med én eller to luker eller 16-QAM r=1/2-modulering i en 2 khz kanal med én enkelt luke, i alminnelighet med plass til overs for ytterligere datapakker (se tabell 2). I den foreliggende utførelsesformen, når det ønskes å sende eller motta taledatapakker på denne måten, angis dette først gjennom passende PDPkontekstforhandling. Spesielt, i den foreliggende utførelsesformen, kan en ny protokolltype bli angitt under forhandling av PDP-kontekst, svarende til "TETRA-taleprotokollen" ifølge den foreliggende utførelsesformen. Dette setter SwMI'en og MS'en i stand til å gjenkjenne når de mottar TETRA-talerammer via SNDCP på måten ifølge den foreliggende utførelsesformen og behandle dem følgelig. Tabell 3 illustrerer formatet til en SN-ACTIVATE PDP CONTEXT DEMAND-PDU (melding) i TETRA som anvendes for å beordre aktivering av den aktuelle PDPkonteksten for TETRA-tale i samsvar med den foreliggende utførelsesformen. Tabell 3: SN-ACTIVATE PDP CONTEXT DEMAND-PDU i TETRA Informasjonselement Lengde Type C/O/M Merknad SN PDU-type 4 1 M SN-ACTIVATE PDP CONTEXT DEMAND SNDCP-versjon 4 1 M NSAPI 4 1 M Se merknad 1 og 2 ATID (Address Type Identifier in 3 1 M Demand) IP-adresse IPv4 32 C Se merknad 3 NSAPI 4 C Se merknad 4 og Pakkedata MS-type 4 1 M PCOMP-forhandling 8 1 M Antall Van Jacobson 8 C Se merknad 6 komprimeringstilstandsluker Antall komprimeringstilstandsluker,tcp 8 C Se merknad 7 Antall komprimeringstilstandsluker, 16 C Se merknad 7