SE470504B - Sätt att i ett GSM-nät ta emot data för tilläggstjänster i MSC/VLR. - Google Patents

Description

2 closed user group, och SS-data beskriver slutligen datastruk- turen för övriga tilläggstjänster, vilka ej faller under någon av de ovan uppräknade kategorierna.

Dessa datatyper innehåller i sin tur det specifika datat för 3 respektive tilläggstjänst. För t.ex. call forwarding tjänster finns det en hel del data som är gemensamt för dessa, därför i beskrivs call forwarding data generellt som Forwardinglnfo. Data för tilläggstjänster är alltså till viss del generell data, och till viss del specifik data för respektive tilläggstjänst.

Datatyperna Forwardingïnfo, CallBarringInfo samt SS-data har en gemensam egenskap, vilket är att den första datatypen internt är SS-code.

SS-code är en datatyp som identifierar en viss SS (Supplemen- tary Service=tilläggstjänst). Samtliga tilläggstjänster i GSM identifieras alltså med hjälp av en SS-code. Undantaget till denna regel är tilläggstjänsten CUG.

Man kan sammanfatta ovanstående på ett enklare sätt som att MAP innehåller sekvenser av "behållare" för tilläggstjänstdata.

Respektive "behållare" har alltid en parameter som visar vilken tjänst som innehållet i "behållaren" avser (i MAP är denna parameter “SS-code"), tillsammans med datat vilket varierar från tjänst till tjänst. Parametern som identifierar avsedd tjänst finns alltid på samma ställe internt inom "behållaren", vilket innebär att man på samma sätt oavsett tjänst kan identifiera mottagaren av datat.

Teknikens ståndpunkt.

EP 454 647 beskriver dirigering av uppringningar till mobila abonnenter. Den mobila abonnentens hemmaväxeln upprätthåller information beträffande var den mobila abonnenten kan finnas.

Vid mottagande i en avfrågningsväxel (“interrogation exchange") av ett anrop till en mobil, begär avfrågningsväxeln information från hemmaväxeln om vart det inkommande anropet skall föras.

Först begär dock hemmaväxeln att växeln där mobilen antas be- finna sig skall utföra paging av mobilen. Resultatet rapporteras till hemmaväxeln, varefter hemmaväxeln informerar avfrågnings- växeln (“interrogation exchange") om var mobilen är lokaliserad.

US 4 644 351 avser sändning av meddelanden via en radiokanal från en av ett flertal fixa centrala platser med olika täckning till fjärrenheter. Varje fjärrenhet är tilldelad en unik adress 3 och är knuten till en av de centrala platserna. När ett med- delande till en utvald fjärrenhet accepteras i en central plats, lagras det i en "paging site" knuten till den utvalda fjärren- heten. En fil med fjärrenhetsadresser tillsammans med lägena för de fjärrenheter, vilka inte befinner sig i täckningsområdet till sina anknutna central-platser, genomsöks för lokalisering av den utvalda fjärrenheten. Om fjärrenheten inte befinner sig i radio- täckningsområdet för centralplatsen, till vilken den är knuten, överförs medelandet och adress till den centralplats, som är angiven i adressfilen.

US 4 700 374 hänför sig till mobiltelefonlokalisering. Ett flertal mobiltelefonväxlar övervakar närvaron för mobiltelefo- nenheter i sina egna områden och är anslutna till ett national- center. Nationalcentret kan motta förfrågningar beträffande lokalisering av mobiltelefon-enheter från var och en av mobilte- lefonväxlarna och överföra lokaliseringsinformation via satellit till alla mobiltelefonväxlarna i systemet. Lokaliseringsinforma- tion innehållande information, som hänför sig till mobiltelefon- växelns och mobiltelefonens identitet, sänds av nationalcentret till den mobiltelefonväxel, som utfärdade förfrågan för att möjliggöra för växeln att åstadkomma förbindelse.

US 4 752 951 beskriver lokalisering av personer. En “PERSONAL LOCATION UNIT" innehåller "personal location units" 12 och en basstation 6. Uppgifter om abonnentlokaliseringar sänds till en databas 5.

US 4 901 340 avser teknik för att tillåta en rörlig mobil- telefonabonnent att i ett främmande område utanför sitt hemmaom- råde motta anrop ställda till hans hemmaområde. I det främmande områdets MTSO mottas information om att abonnenten, i det främ- mande området, önskar motta anrop ställda till hans hemmaområde.

Han tilldelas, för utnyttjande i det främmande området, ett "temporary directory number" (TDN).

US 5 090 050 beskriver kommunikation med radiotelefoner till- höriga ett radiotelefonsystem, när dessa opererar i ett annat geografiskt område betjänat av ett annat radiotelefonsystem.

Radiotelefonanvändaren sänder via telefon en signal för aktive- ring i en databas i hemmasystemet. Aktiveringssignalen identifi- erar radiotelefonen och det andra radiotelefonsystemet, vilket betjänar det område där radiotelefonen befinner sig temporärt. 4 Vid mottagning av ett anrop för radiotelefonen söks databasen efter aktiveringssignalen och anropet förs till det andra syste- met via en landtelefonlinje. Därefter upprättas radiokommunika- tion mellan det andra systemet och radiotelefonen.

Redogörelse för uppfinningen.

Syftet med föreliggande uppfinning är att ange en generell lösning för mottagning av data för tilläggstjänster i MSC/VLR, vilka har signalerats via MAP mellan HLR och MSC/VLR. Lösningen skall medge att nya tilläggstjänster kan läggas till i MSC/VLR, utan att man påverkar de funktioner som hanterar termineringen av MAP-protokollet i MSC/VLR.

Detta syfte har enligt uppfinningen uppnåtts genom att, vid ett sätt av det inledningsvis ovan definierade slaget, en funk- tion införs med uppgift att syntaktiskt analysera i MAP mottagen abonnentdata, så långt att respektive tilläggstjänst kan identi- fieras, varvid när rätt tilläggstjänst har identifierats med hjälp av datatypen SS-code, denna ges tillgång till innehållet i "behållaren", varpå respektive tillläggstjänst syntaktiskt analyserar de datatyper som ingår i "behållaren", enligt en struktur som bara är känd i respektive tilläggstjänst, och data sedan lagras lokalt per tilläggstjänst i MSC/VLR.

Enligt en föredragen utföringsform utföres följande funk- tionsmoment: A) 1. innehållet i datatypen SS-infolist, dvs den lista, som anger datatyper i MAP, analyseras syntaktiskt för att identifie- ra de "behållare", som finns inkluderade i "SS-infolist". 2. data-typen SS-code identifieras internt inom respekti- ve "behållare", B) 1. värdet för SS-code analyseras med säkerställande av att nya värden för SS-code kan läggas till utan att påverka funktionen, som utför analysen, varvid varje gång analysen utförs en tilläggstjänst pekas ut, 2. denna tilläggstjänst anropar en funktion under A, som vid begäran från tjänst ger innehåll i "behållare", varvid innehållet i "behållaren", dvs de för denna tjänst specifika datatyperna, analyseras internt inom funktionen för tilläggs- tjänsten. 3. momenten B1-2 repeteras tills samtliga "behållare" har gåtts igenom och alla "behållare" har levererats till respektive nu. ~ mottagande tilläggstjänst, varvid "behållare", som inte motsva- rar någon tilläggstjänst implementerad i MSC/VLR kastas.

V Datastrukturen i MAP beskrivs såsom ovan nämnts generellt enligt ASN.1 (Abstract Syntax Notation). Genom uppfinningen kan datatyper beskrivna enligt ASN.1 syntax implementeras i MSC/VLR så att tillägg kan ske av nya tilläggstjänster i MSC/VLR, vilka tillför sina egna datatyper, utan att man påverkar de funktio- ner, som hanterar terminering av MAP-protokollet i MSC/VLR.

Föredragen utföringsform.

Enligt uppfinningen implementerar man en generell funktion vars uppgift är att syntaktiskt analysera i MAP mottagen abon- nentdata, så långt att respektive tilläggstjänst kan identi- fieras. När rätt tilläggstjänst har identifierats med hjälp av datatypen SS-code, kan denna få tillgång till innehållet i "behållaren". Det är nu upp till respektive tilläggstjänst att syntaktiskt analysera de datatyper som ingår i "behållaren", enligt den struktur som bara är känd i respektive tilläggs- tjänst. Data lagras sedan lokalt per tilläggstjänst i MSC/VLR.

Funktionen som löser detta i MSC/VLR är uppdelad i två områden här benämnda delfunktion A resp. delfunktion B, vilkas utföringsmoment framgår nedan.

Delfunktion A.

- Analysera "SS-infolist." - Identifiera första "behållare".

Identifiera “SS-code" - Anropa delfunktion B.

Ulm-www I - Identifiera nästa behållare.

Gå till 3.

Upprepas tills alla behållare. gåtts igenom. 6 - Vid anrop från "tjänst", ge innehållet i behållare.

Delfunktion B. l - Analysera "SS-code". 2 - Anropa ägare av "SS-code" (dvs tjänst som äger "SS-code"). 3 - Om ingen ägare finns, kasta "behållaren". 6 4 - Vid anrop från "tjänst", lagra information om vilken tjänst, som äger resp. "SS-code".

Delfunktion A analyserar syntaktiskt innehållet i datatypen SS-infolist (se ovan) för att kunna identifiera alla "behållare" i SS-infolist. Dessutom identifieras datatypen SS-code internt inom respektive "behållare". För varje "behållare" kommer den andra delfunktionen, här kallad delfunktion B, att kallas in, vilken har i uppgift att identifiera rätt tilläggstjänst.

Delfunktion B kommer att analysera värdet för SS-code. Denna analys är så konstruerad att man kan lägga till nya värden för SS-code utan att påverka funktionen vilken utför analysen.

För varje gång analysen av SS-code utförs kommer en till- läggstjänst att pekas ut. Denna tilläggstjänst kan nu anropa delfunktion A för att få tillgång till innehållet, dvs data, i "sin behållare". Innehållet i "behållaren" (datatyperna speci- fika för denna tjänst) analyseras nu internt inom funktionen för tilläggstjänsten.

Detta förfarande repeteras nu, ända till samtliga "behållare" har gåtts igenom och alla "behållare" har levererats till re- spektive mottagande tilläggstjänst. Sådana "behållare" som inte motsvarar någon tilläggstjänst kan kastas, då dessa innehåller data för en tjänst som inte finns implementerad i MSC/VLR.

Denna generella lösning för mottagning av abonnentdata för tilläggstjänster i MSC/VLR medger att basfunktionen vilken mottar abonnentdata kan konstrueras på sådant sätt att nya till- läggstjänster inkrementellt kan läggas till i MSC/VLR utan att basfunktionen behöver modifieras.

Detta ger mycket goda egenskaper vid konstruktion av till- läggstjänster, som ofta är optionella för en MSC/VLR operatör, och sålunda kan läggas till var för sig utan att de påverkar basfunktionerna i MSC/VLR, i detta fall med avseeende på mottag- ning av abonnentdata från HLR.

Nedan sammanfattas i listform momenten i samband med arbete med och utnyttjande av den tjänst, som äger SS-code.

Tjänst som äger "SS-code" 1 - Vid inläggning av ny tjänst i MSC/VLR, rapportera "SS-code" till funktion B (anropa delfunktion B-4). 2 - Vid anrop från funktion B, anropa delfunktion ~\ 7 A-6 med begäran att få tillgång till innehållet i "behållaren".

Utförandet av mjuk- och hårdvara för att möjliggöra ovan beskrivna funktioner torde vara självklart för fackmannen och behöver därför ej beskrivas närmare här.

Claims (3)

Patentkrav.

1. Sätt att i ett GSM-nät ta emot data för tilläggstjänster i MSC/VLR, vilka har signalerats via protokollet MAP mellan HLR och MSC/VLR, varvid MAP innehåller sekvenser av "behållare" för tilläggstjänstdata, där respektive "behållare" alltid har en parameter som visar vilken tjänst som innehållet i "behållaren" avser, tillsammans med datat vilket varierar från tjänst till tjänst, vilken parameter alltid finns på samma ställe internt inom “behållaren", kännetecknat av att en funktion införs med uppgift att syntaktiskt analysera i MAP mottagen abonnentdata, så långt att respektive tilläggstjänst kan identifieras, varvid när rätt tilläggstjänst har identifierats med hjälp av datatypen SS-code, denna ges tillgång till innehållet i "behå1laren", varpå respektive tillläggstjänst syntaktiskt analyserar de datatyper som ingår i "behållaren", enligt en struktur som bara är känd i respektive tilläggstjänst, och data sedan lagras lokalt per tilläggstjänst i MSC/VLR. 2. Sätt enligt krav 1, kännetecknat av att följande funk- tionsmoment utföres: A) 1. innehållet i datatypen SS-infolist, dvs den lista, som anger datatyper i MAP, analyseras syntaktiskt för att identifie- ra de "behållare", som finns inkluderade i "SS-infolist", 2. data-typen SS-code identifieras internt inom respekti- ve "behållare", B) 1. värdet för SS-code analyseras med säkerställande av att nya värden för SS-code kan läggas till utan att påverka funktionen, som utför analysen, varvid varje gång analysen utförs en tilläggstjänst pekas ut,

2. denna tilläggstjänst anropar en funktion under A, som vid begäran från tjänst ger innehåll i "behållare", varvid innehållet i "behållaren", dvs de för denna tjänst specifika datatyperna, analyseras internt inom funktionen för tilläggs- tjänsten,

3. momenten Bl-2 repeteras tills samtliga "behållare" har gåtts igenom och alla "behållare" har levererats till respektive mottagande tilläggstjänst, varvid "behållare", som inte motsva- rar någon tilläggstjänst kastas.