ES2565836T3 - Método para transmitir datos de canal de control común - Google Patents
Método para transmitir datos de canal de control común Download PDFInfo
- Publication number
- ES2565836T3 ES2565836T3 ES08842001.3T ES08842001T ES2565836T3 ES 2565836 T3 ES2565836 T3 ES 2565836T3 ES 08842001 T ES08842001 T ES 08842001T ES 2565836 T3 ES2565836 T3 ES 2565836T3
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- mac
- pdu
- field
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 65
- 238000004891 communication Methods 0.000 claims abstract description 17
- 230000005540 biological transmission Effects 0.000 description 23
- 230000008569 process Effects 0.000 description 10
- 230000004044 response Effects 0.000 description 8
- 238000012546 transfer Methods 0.000 description 6
- 108700026140 MAC combination Proteins 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 238000010295 mobile communication Methods 0.000 description 4
- 241000760358 Enodes Species 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 229920001690 polydopamine Polymers 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000005477 standard model Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
Un método de generación de una unidad de datos de protocolo, PDU, en un sistema de comunicación inalámbrico que comprende terminales, el método que comprende: recibir al menos una unidad de datos de servicio, SDU, desde una capa superior a través de un canal lógico común, en donde el canal lógico común es un canal de control común, CCCH; añadir una cabecera a las SDU recibidas para generar la PDU, en donde la cabecera incluye al menos un campo, en donde el al menos un campo identifica un canal lógico de la SDU recibida o un tipo de elemento de control, CE; establecer el al menos un campo para indicar que la al menos una de las SDU incluidas en la PDU generada se recibieron desde el canal de control común, en donde un índice dentro del al menos un campo se fija con un valor fijo aplicado a todos los terminales para indicar el canal de control común y entregar la PDU generada a una capa inferior.
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Metodo para transmits datos de canal de control comun Campo tecnico
La presente invencion se refiere a un sistema de radiocomunicacion (inalambrico) que proporciona un servicio de radiocomunicacion y un terminal y, mas particularmente, a un metodo para intercambiar bloques de datos por una estacion base y un terminal en un Sistema Universal de Telecomunicaciones Moviles Evolucionado (E-UMTS) evolucionado desde el UMTS o un sistema de Evolucion a Largo Plazo (LTE), en el que un lado de transmision transmite eficazmente datos transmitidos a traves de un Canal Logico de Control Comun (CCCH) a un lado de recepcion y el lado de recepcion separa con precision datos innecesarios de los datos recibidos a traves del Canal Logico de Control Comun.
Antecedentes de la tecnica
La Figura 1 muestra una estructura de red ejemplar de un Sistema Universal de Telecomunicaciones Moviles Evolucionado (E-UMTS) como un sistema de comunicacion movil al que se aplican una tecnica relacionada y la presente invencion. El sistema E-UMTS es un sistema que ha evolucionado a partir del sistema UMTS existente y su trabajo de estandarizacion esta siendo realizado actualmente por la organizacion de estandares 3GPP. El sistema E- UMTS tambien se puede conocer como un sistema LTE (Evolucion a Largo Plazo).
La red E-UMTS se puede dividir toscamente en una E-UTRAN y una Red Central (CN). La E-UTRAN comprende de manera general un terminal (es decir, Equipo de Usuario (UE)), una estacion base (es decir, eNodo B), una Pasarela de Servicio (S-GW) que se situa en un extremo de la red E-UMTS y conecta con una o mas redes externas y una Entidad de Gestion de Movilidad (MME) que realiza funciones de gestion de movilidad para un terminal movil. Un eNodo B puede tener una o mas celdas.
La Figura 2 muestra una arquitectura ejemplar de un protocolo de interfaz radio entre un terminal y una E-UTRAN (Red Universal de Acceso Radio Terrestre Evolucionada) segun el estandar de red de acceso radio del 3GPP. El protocolo de interfaz radio se compone horizontalmente de una capa ffsica, una capa de enlace de datos y una capa de red y verticalmente se compone de un plano de usuario para transmitir datos de usuario y un plano de control para transferir senalizacion de control. La capa de protocolo se puede dividir en L1 (Capa 1), L2 (Capa 2) y L3 (Capa 3) en base a las tres capas inferiores del modelo de estandares de Interconexion de Sistemas Abiertos (OSI) que es ampliamente conocido en el campo de sistemas de comunicacion.
En lo sucesivo, se describiran mas adelante capas particulares del plano de control de protocolo radio de la Fig. 2 y del plano de usuario de protocolo radio de la Fig. 3.
La capa ffsica (Capa 1) usa un canal ffsico para proporcionar un servicio de transferencia de informacion a una capa superior. La capa ffsica se conecta con una capa de control de acceso al medio (MAC) situada por encima de la misma a traves de un canal de transporte y se transfieren datos entre la capa ffsica y la capa MAC a traves del canal de transporte. Tambien, entre diferentes capas ffsicas respectivamente, esto es, entre las capas ffsicas respectivas del lado de transmision (transmisor) y el lado de recepcion (receptor), se transfieren datos a traves de un canal ffsico.
La capa de Control de Acceso al Medio (MAC) de la Capa 2 proporciona servicios a una capa de control de enlace radio (RLC) (que es una capa superior) a traves de un canal logico. La capa RLC de la Capa 2 soporta la transmision de datos con fiabilidad. Se debena senalar que si las funciones RLC se implementan en y realizan por la capa MAC, la capa RLC en sf misma puede no necesitar existir. La capa PDCP de la Capa 2 realiza una funcion de compresion de cabecera que reduce informacion de control innecesaria de manera que los datos que se transmiten empleando paquetes de Protocolo de Internet (IP), tales como IPv4 o IPv6, se pueden enviar eficientemente sobre una interfaz radio que tiene un ancho de banda relativamente pequeno.
La publicacion de solicitud de patente de EE.UU. N° 2006/067364 A1 describe un esquema de procesamiento de Capa de Acceso al Medio (MAC) para minimizar el tamano de informacion de correlacion contenida en una PDU de MAC.
La Especificacion Tecnica del 3GPP TS 36.321, V1.0.0, es una especificacion tecnica del 3GPP de un protocolo MAC para redes eUTRA.
La capa de Control de Recursos Radio (RRC) situada en la parte mas baja de la Capa 3 se define solamente en el plano de control y maneja el control de canales logicos, canales de transporte y canales ffsicos con respecto a la configuracion, reconfiguracion y liberacion de portadores radio (RB). Aqrn, el Rb se refiere a un servicio que se proporciona por la Capa 2 para transferencia de datos entre el terminal movil y la UTRAN.
Los RB se refieren a un camino logico proporcionado por la primera y segunda capas del protocolo radio para transmision de datos entre el terminal y la UTRAN. En general, configuracion (o establecimiento) del RB se refiere al
5
10
15
20
25
30
35
40
45
50
proceso de estipulacion de las caractensticas de una capa de protocolo radio y un canal requerido para proporcionar un servicio particular y establecer los parametros detallados y metodos operacionales respectivos. Un estado RRC se refiere a si existe una conexion logica para intercambiar mensajes RRC entre la capa RRC de un terminal espedfico y la capa RRC de la UTRAN. Si hay una conexion, se dice que el terminal esta en estado conectado RRC. Si no hay conexion, se dice que el terminal esta en estado inactivo.
El canal logico es un canal definido entre una entidad RLC y una entidad MAC y se puede dividir segun las caractensticas de datos en el canal logico. El canal de transporte es un canal definido entre la capa ffsica y la entidad MAC y se puede dividir segun un esquema de transmision en el que se transmiten datos en el canal de transporte.
En general, el Canal de Control Comun (CCCH) es un canal de control comun y se usa cuando un terminal envfa un mensaje a una estacion base en un estado que el terminal no tiene una conexion RRC con la estacion base o cuando un terminal envfa un mensaje RRC en un estado que el terminal tiene una conexion RRC con una cierta estacion base excepto si una estacion base a la que esta accediendo actualmente el terminal es diferente de la estacion base que tiene la conexion RRC con el terminal. El CCCH tambien se usa cuando la estacion base va a enviar un mensaje RRC a un terminal que no tiene conexion RRC con la estacion base.
Por el contrario, en estado conectado RRC, cuando el terminal y la estacion base intercambian mensajes de control (por ejemplo, mensajes RRC) o datos de usuario, se usa un Canal de Control Dedicado (DCCH) o Canal de Trafico Dedicado (DTCH). En este caso, hay una necesidad de distinguir eficazmente un mensaje transmitido a traves del CCCH a partir de un mensaje o datos transmitidos a traves del DTCH/DCCH. Por esto, segun la tecnica relacionada, la estacion base y el terminal usan una pluralidad de Identificadores Temporales de Red Radio de Celda (C-RNTI) para distinguir los canales anteriores unos de otros. Por ejemplo, cuando se notifica una transmision del Canal Compartido de Enlace Descendente Ffsico (PDSCH) o Canal Compartido de Enlace Ascendente Ffsico (PUSCH) a traves del Canal de Control de Enlace Descendente Ffsico (PDCCH), se usa un C-RNTI A si se transmiten datos del CCCH a traves del PDSCH o PUSCH y se usa un C-RNTI B si se transmiten datos del DTCH o DCCH. No obstante, este metodo puede causar el gasto de consumo de potencia y un aumento de complejidad, considerando que el lado de recepcion debena monitorizar siempre la pluralidad de los C-RNTI.
Para un terminal que no tiene conexion RRC, no se asigna el C-RNTI. En este caso, es diffcil discriminar a traves del C-RNTI si los datos pertenecen a que canal logico, haciendo por ello diffcil de usar el metodo anterior.
Ademas, para un terminal antes de tener la conexion RRC, el terminal no tiene ningun RB establecido con la estacion base. Por el contrario, un terminal que tiene la conexion RRC tiene varios RB establecidos con la estacion base. Esto significa, desde una perspectiva de la entidad MAC que sirve para manejar la correlacion del canal de transporte y el canal logico, distinguir contenidos de cada mensaje transmitido/recibido durante el procedimiento RACH. Es decir, hay una necesidad de tener un metodo para distinguir cada caso en base a la perspectiva de la Unidad de Datos de Protocolo (PDU) de MAC.
Descripcion de la invencion
Solucion tecnica
Por lo tanto, un objeto de la presente invencion es proporcionar un metodo para distinguir eficazmente el tipo de cada uno de los datos y mensajes de control en un proceso de intercambio de los datos y los mensajes de control entre una estacion base y un terminal.
Mas espedficamente, la presente invencion va a proporcionar un metodo para distinguir facilmente datos de CCCH de datos no de CCCH y transmitir eficazmente los mismos, en un proceso en que una entidad MAC regenera (o reconfigura) una PDU de MAC recibida en una SDU de MAC para entregar la misma a una capa superior o genera la SDU de MAC recibida desde la capa superior en una PDU de MAC para transmitir la misma.
Para lograr estas y otras ventajas y segun el proposito de la presente invencion, como se concreta y describe ampliamente en la presente memoria, se proporciona un metodo de generacion de una unidad de datos de protocolo (PDU) en un sistema de comunicacion inalambrico como se expone en las reivindicaciones adjuntas.
Breve descripcion de los dibujos
La Figura 1 muestra una estructura de red ejemplar de una Red Universal de Acceso Radio Terrestre Evolucionada (E-UTRAN) como un sistema de comunicacion movil al que se aplican una tecnica relacionada y la presente invencion;
La Figura 2 muestra una vista ejemplar de arquitectura de plano de control de la tecnica relacionada de un protocolo de interfaz radio entre un terminal y una E-UTRAN;
La Figura 3 muestra una vista ejemplar de la arquitectura de plano de usuario de la tecnica relacionada de un protocolo de interfaz radio entre un terminal y una E-UTRAN;
5
10
15
20
25
30
35
40
La Figura 4 ilustra un formato de Unidad de Datos de Protocolo (PDU) ejemplar usado en una entidad de Control de Acceso al Medio (MAC);
Las Figuras 5a y 5b ilustran formates de subcabecera de MAC ejemplares usados en una entidad MAC;
La Figura 6 muestra un procedimiento de conexion RRC ejemplar entre un terminal y una red;
La Figura 7 muestra un procedimiento de conexion inicial ejemplar de un terminal; y
Las Figuras 8a y 8b ilustran campos de LCID ejemplares de una subcabecera de MAC usada segun la presente invencion.
Modo para la invencion
Un aspecto de la presente invencion es el reconocimiento por los presentes inventores con respecto a los problemas e inconvenientes de la tecnica relacionada descrita anteriormente y explicada en mas detalle en lo sucesivo. En base a tal reconocimiento, se han desarrollado los rasgos de la presente invencion.
La presente invencion se aplica a una tecnica de comunicacion del 3GPP, en particular, un sistema Universal de Telecomunicaciones Moviles, aparato de comunicacion y metodo de comunicacion. No obstante, sin que se limite a este, la presente invencion se puede aplicar a todas las comunicaciones cableadas/inalambricas a las que son aplicables los rasgos tecnicos de la presente invencion.
La presente invencion se refiere conceptualmente a un metodo de generacion de una unidad de datos de protocolo (PDU) en un sistema de comunicacion inalambrico que intercambia bloques de datos o unidades de datos entre una estacion base y un terminal, el metodo que comprende: recibir al menos una unidad de datos de servicio (SDU) desde una capa superior a traves de un canal logico comun; anadir una cabecera a las SDU recibidas para generar la unidad de datos de protocolo (PDU), en donde la cabecera incluye al menos un campo, en donde el al menos un campo se usa para identificar un canal logico o se usa para identificar un tipo de informacion de control, establecer el al menos un campo para indicar que la al menos una de las SDU incluidas en la PDU generada se recibieron desde el canal logico comun, entregar la PDU generada a una capa inferior y un terminal de comunicacion inalambrico capaz de realizar tal metodo.
En lo sucesivo, se dara una descripcion de estructuras y operaciones de las realizaciones preferidas segun la presente invencion con referencia a los dibujos anexos.
La Figura 4 ilustra un formato de Unidad de Datos de Protocolo (PDU) de MAC usado en una entidad de Control de Acceso al Medio (MAC). Como se muestra en la Fig. 4, el campo de ID de Canal Logico (LCID) identifica un ejemplo de canal logico de una SDU de MAC correspondiente y el campo de Longitud (L) indica una longitud de la SDU de MAC correspondiente en bytes. El campo de Extension (E) indica si estan presentes o no mas campos en una cabecera. En el proceso anterior, si un tamano de la SDU de MAC correspondiente o Elemento de Control de MAC es menor o igual que 127, se puede usar un campo L de 7 bits como se muestra en la Fig. 5. Si el tamano de la SDU de MAC o el Elemento de Control de MAC correspondiente es mayor que 127, se puede usar el campo L de 15 bits como se muestra en la Fig. 5. Y, una subcabecera de MAC como se muestra en la Fig. 5(b) se puede usar para una subcabecera de MAC de la SDU de MAC incluida en la PDU de MAC o un Elemento de Control de MAC de tamano fijo. Una subcabecera de MAC como se muestra en la Fig. 5(a) se puede usar para otros casos.
A continuacion, se daran en mas detalle descripciones de cada campo usado en la Fig. 4.
- LCID: indica el tipo de datos de canal logico de la SDU de MAC correspondiente o el tipo de datos contenidos en el Elemento de Control de MAC (CE de MAC) correspondiente.
- E: indica si otra subcabecera de MAC es o no posterior a la subcabecera de MAC actual.
- Formato (F): indica una longitud del campo L posterior.
- Reservado (R): indica un bit reservado y es un bit no usado.
Aqrn, se mostrara a continuacion informacion relacionada con los valores de LCID.
Tabla 1. Valores de LCID para DL-SCH
- Indice
- Valores de LCID
- 00001-xxxxx
- Identidad del canal logico
- xxxxx-11011
- Reservado
- 11100
- Identidad de Resolucion de Contencion de UE
5
10
15
20
25
30
35
- Indice
- Valores de LCID
- 11101
- Avance de Temporizacion
- 11110
- Comando de DRX
- 11111
- Relleno
Tabla 2. Valores de LCID para UL-SCH
- Indice
- Valores de LCID
- 00000-yyyyy
- Identidad del canal logico
- yyyyy-11011
- Reservado
- 11100
- Informe de Margen de Potencia
- 11101
- Informe de Estado de Almacenador Temporal Corto
- 11110
- Informe de Estado de Almacenador Temporal Largo
- 11111
- Relleno
En lo sucesivo, se dara en detalle una descripcion de un estado RRC de un terminal y un metodo de conexion RRC. El estado RRC se refiere a si se conecta logicamente el RRC del terminal al RRC de la E-UTRAN, formando por ello una conexion logica con el RRC de la E-UTRAN. Si el RRC del terminal forma una conexion logica con el RRC de la E-UTRAN, esto se conoce como un “estado conectado RRC”. Por el contrario, si no hay ninguna conexion logica entre el RRC del terminal y el RRC de la E-UTRAN, esto se conoce como un “estado inactivo RRC”. Cuando el terminal esta en el estado conectado RRC y, por consiguiente, la E-UTRAN puede reconocer la existencia del terminal correspondiente segun unidades de celdas, la E-UTRAN puede controlar eficazmente el terminal. Por otra parte, la E-UTRAN no puede reconocer un terminal que esta en estado inactivo. El terminal en estado inactivo se puede gestionar por la red central segun unidades de areas de localizacion o unidades de areas de seguimiento, que son areas mas grandes que la celda. Aqm, el area de seguimiento es un conjunto de celdas. Espedficamente, la existencia de un terminal en estado inactivo se reconoce solamente segun unidades de areas grandes, tales como areas de localizacion o areas de seguimiento (encaminamiento) y el terminal debe transitar en el estado conectado a fin de recibir servicios de comunicacion moviles tfpicos tales como voz o datos.
Cuando un usuario conecta inicialmente la alimentacion del terminal, el terminal en primer lugar puede detectar una celda adecuada y mantiene su estado en un estado inactivo en esta celda. El terminal en estado inactivo forma una conexion RRC con el RRC de la E-UTRAN a traves del procedimiento de conexion RRC y transita al estado conectado RRC cuando la conexion RRC necesita ser formada. Hay varios casos en los que se requiere un terminal en estado inactivo para formar la conexion RRC. Por ejemplo, se puede requerir una transmision de datos de enlace ascendente debido a un intento de llamada por un usuario o se puede requerir la transmision de un mensaje de respuesta en respuesta a un mensaje de busqueda recibido desde la E-UTRAn.
A fin de que un terminal en estado inactivo forme una conexion RRC con la E-UTRAN, se debena realizar el procedimiento de conexion RRC que se describio anteriormente. El procedimiento de conexion RRC se compone principalmente de tres pasos de transmision, por el terminal, de un mensaje de solicitud de conexion RRC a la E- UTRAn, transmitiendo, por la E-UTRAN, un mensaje de establecimiento de conexion RRC al terminal y transmitiendo, por el terminal, un mensaje de establecimiento de conexion RRC completa a la E-UTRAN. Tal procedimiento de conexion RRC se muestra en la Fig. 6.
Mas espedficamente, si el terminal en estado inactivo necesita formar una conexion RRC debido a un intento de llamada o una respuesta a una busqueda desde la E-UTRAN, el terminal puede transmitir un mensaje de solicitud de conexion RRC a la E-UTRAN (Paso 1). Aqm, el mensaje de solicitud de conexion RRC puede incluir un identificador de UE inicial, una causa de establecimiento RRC y similares. El identificador de UE inicial es un identificador unico de terminal y sirve para identificar un terminal correspondiente en cualquier region en todo el mundo. Hay varias causas de establecimiento RRC, incluyendo un intento de llamada o una respuesta a una busqueda. Tras transmitir el mensaje de solicitud de conexion rRc, el terminal puede activar un temporizador. Si el terminal deja de recibir un mensaje de establecimiento de conexion RRC o un mensaje de rechazo de conexion RRC desde la E-UTRAN hasta que el temporizador expire, el terminal retransmitma el mensaje de solicitud de conexion RRC. Un numero maximo de transmisiones del mensaje de solicitud de conexion RRC se puede limitar a un valor espedfico.
5
10
15
20
25
30
35
40
45
50
55
60
Tras recibir el mensaje de solicitud de conexion RRC desde el terminal, la E-UTRAN puede aceptar la solicitud de conexion RRC del terminal si los recursos radio son suficientes y puede transmitir un mensaje de establecimiento de conexion RRC como un mensaje de respuesta al terminal (Paso 2). Aqm, el mensaje de establecimiento de conexion RRC se transmite incluyendo un Identificador Temporal de Red Radio de Celda (C-RNTI) e informacion de establecimiento de RB junto con el identificador de UE inicial. El C-RNTI es un identificador de UE, que se asigna por la E-UTRAN, para identificar un terminal en estado conectado. El C-RNTI se puede usar solamente cuando hay una conexion RRC y solamente dentro de la E-UTRAN. Despues de formar la conexion RRC, el terminal puede comunicar con la E-UTRAN usando el C-RNTI, en lugar de usar el identificador de UE inicial. Esto es debido a que el identificador de UE inicial es el identificador unico de terminal, por lo tanto, si este se usa frecuentemente, se puede filtrar. Por consiguiente, debido a una razon de seguridad, el identificador de UE inicial se puede usar temporalmente durante el procedimiento de conexion RRC solamente, se puede usar el C-RNTI en su lugar de despues del procedimiento de conexion RRC.
Habiendo recibido el mensaje de establecimiento de conexion RRC, el terminal puede comparar el identificador de UE inicial incluido en el mensaje con su propio identificador y puede comprobar si se transmite o no el mensaje recibido para el terminal por sf mismo. En base al resultado comprobado, si el mensaje se transmite al terminal, el terminal puede almacenar un C-RNTI asignado por la E-UTRAn y entonces puede transmitir un mensaje de establecimiento de conexion RRC completo a la E-UTRAN usando el C-RNTI (Paso 3). Aqm, el mensaje de establecimiento de conexion RRC completo incluye informacion del rendimiento del terminal. Si el terminal transmite con exito el mensaje de establecimiento de conexion RRC, el terminal forma la conexion RRC con la E-UTRAN y se mueve al estado conectado RRC.
En lo sucesivo, se daran en mas detalle descripciones de un Canal de Acceso Aleatorio (RACH) a traves del cual un terminal transmite un mensaje de control inicial a una red. En general, hay varias razones para usar el RACH: para sincronizacion de tiempo de un terminal con una red y para adquirir recursos radio cuando el terminal necesita una transmision de datos de enlace ascendente pero no hay recursos radio de enlace ascendente para transmitir tales datos. Por ejemplo, el terminal se enciende para acceder inicialmente a una nueva celda. En este caso, el terminal realizana sincronizacion de enlace descendente y recibina informacion de sistema de una celda a la que desea acceder. Despues de recibir la informacion de sistema, el terminal transmitina un mensaje de solicitud de conexion RRC para la conexion RRC. No obstante, el terminal no esta sincronizado en tiempo con una red actual y tampoco adquiere recursos radio de enlace ascendente. Por consiguiente, el terminal puede usar el RACH para solicitar recursos radio para transmitir el mensaje de solicitud de conexion RRC a la red. La estacion base, que ha recibido la solicitud de recursos radio correspondiente, puede asignar recursos radio adecuados al terminal. Entonces, el terminal puede transmitir el mensaje de solicitud de conexion RRC a la red usando los recursos radio. En otro ejemplo, se supone que el terminal tiene una conexion RRC con la red. En este caso, el terminal puede recibir recursos radio dependiendo de la programacion de recursos radio de la red y puede transmitir datos a la red a traves de los recursos radio. No obstante, si no habfa datos a ser transmitidos en un almacenador temporal del terminal, la red no asignana ademas recursos radio de enlace ascendente al terminal. Esto es debido a que es ineficiente asignar los recursos radio de enlace ascendente al terminal, el cual no tiene datos a ser transmitidos. Aqm, un estado de almacenador temporal del terminal se puede notificar a la red periodicamente o tras la aparicion de un evento. Si existen ahora nuevos datos a ser transmitidos en el almacenador temporal del terminal que no tiene recursos radio, el terminal usana el RACH dado que no tiene asignados recursos radio de enlace ascendente. Es decir, el terminal puede usar el RACH para solicitar los recursos radio requeridos para transmision de datos desde la red.
La Figura 7 muestra un procedimiento de conexion inicial ejemplar de un terminal. Como se muestra en la Fig. 7, un terminal puede seleccionar una Firma de Acceso Aleatorio disponible y una Ocasion de Acceso Aleatorio a traves de informacion de sistema recibida desde una estacion base a traves de una senal RRC y entonces puede transmitir un Preambulo de Acceso Aleatorio (en lo sucesivo, conocido como mensaje 1) a la estacion base (Paso 1). Despues de recibir con exito el preambulo de acceso aleatorio del terminal, la estacion base transmite una Respuesta de Acceso Aleatorio (en lo sucesivo, conocida como mensaje 2) al terminal (Paso 2). Aqm, la respuesta de acceso aleatorio puede incluir un Avance de Tiempo (TA) que es informacion de sincronizacion de tiempo de enlace ascendente con la estacion base, una concesion inicial que es informacion con respecto a una asignacion de recursos radio de enlace ascendente de un identificador C-RNTI a ser usado en una celda correspondiente y similares. Despues de recibir la respuesta de acceso aleatorio, el terminal puede generar y transmitir una PDU de MAC (en lo sucesivo, conocida como un mensaje 3) segun informacion relacionada con la asignacion de recursos radio incluida en la informacion de respuesta de acceso aleatorio (Paso 3). Dependiendo del mensaje 3 recibido desde el terminal, la estacion base puede asignar recursos radio o puede transmitir el mensaje RRC (Paso 4).
En general, la estacion base y el terminal pueden transmitir o recibir datos a traves de un canal ffsico el Canal Compartido de Enlace Descendente Ffsico (PDSCH) usando un canal de transporte DL-SCH, con la excepcion de una senal de control espedfico o datos de un servicio particular. Tambien, informacion sobre que terminal (o una pluralidad de terminales) debena recibir datos del PDSCH e informacion sobre como los terminales debenan recibir los datos de PDSCH y realizar decodificacion, se transmiten estando incluidos en el canal ffsico el Canal de Control de Enlace Descendente Ffsico (PDCCH).
5
10
15
20
25
30
35
40
45
50
55
Por ejemplo, se supone que un cierto PDCCH esta bajo enmascaramiento CRC como un RNTI (Identificador Temporal de Red Radio) “A” y que se transmite en una cierta subtrama incluyendo informacion acerca de datos que se transmiten en informacion de formato de transferencia “C” (por ejemplo, un tamano de bloque de transporte, informacion de modulacion y codificacion, etc.) a traves de recursos radio “B” (por ejemplo, una localizacion de frecuencia). Bajo tal condicion, uno o mas terminales en una celda correspondiente pueden monitorizar el PDCCH usando su propia informacion de RNTI. Si hay uno o mas terminales que tienen RNTI A en un punto de tiempo correspondiente, los terminales recibiran el PDCCH y a traves de informacion del PDCCH recibido, tambien recibiran un PDSCH indicado por B y C.
Como se describio anteriormente, la presente invencion va a proporcionar un metodo para distinguir eficazmente el tipo de cada uno de los datos y mensajes de control en un proceso de intercambio de los datos y los mensajes de control entre la estacion base y el terminal. En particular, la presente invencion va a proporcionar un metodo para distinguir facilmente datos de CCCH de datos no de CCCH y transmitir eficazmente los mismos, en un proceso en que una entidad MAC regenera una PDU de MAC recibida en una SDU de MAC para entregar la misma a una capa superior o genera la SDU de MAC recibida desde la capa superior en una PDU de MAC para transmitir la misma.
Para esto, la presente invencion propone, si el terminal transmite datos del canal logico de control comun, fijar un campo de LCId de una subcabecera de MAC de datos con un valor especial para transmision cuando la entidad MAC del terminal genera la PDU de MAC usando los datos.
Ademas, la presente invencion propone, si el terminal transmite datos del canal logico de control no comun, fijar el campo de LClD de la subcabecera de MAC de datos con un valor especial para un canal logico relacionado con los datos cuando la entidad MAC del terminal genera la PDU de MAC usando los datos. Aqrn, el valor fijo para el canal logico se puede notificar por la estacion base al terminal a traves del mensaje RRC mientras que se realiza el procedimiento de establecimiento de conexion RRC o el procedimiento de establecimiento de llamada.
Mas espedficamente, en la presente invencion, cuando el terminal transmite la PDU de MAC a traves del mensaje RACH 3 descrito en la Fig. 7, si el mensaje RRC se incluye en la PDU de MAC y el terminal no esta en modo conectado RRC aun, el terminal puede fijar el campo de LCID en la cabecera de PDU de MAC con un valor especial y puede transmitir el mismo. Ademas, durante el proceso anterior, el valor especial puede indicar que los datos incluidos en la PDU de MAC que incluyen el LCID son los datos de CCCH. Es decir, la presente invencion no fija el campo de LCID usado para la transmision del mensaje de CCCH con un valor unico a cada terminal, sino que usa un valor fijo aplicado a todos los terminales. Ademas, la presente invencion propone usar el campo de LCID para notificar el tipo de un canal logico de datos que se transmiten. Es decir, el campo de LCID no se usa para determinar si son datos de DCCH o datos no de DCCH, sino que se usa al menos para saber si son o no datos de CCCH.
La presente invencion considera que, en el procedimiento RACH, los recursos radio para transmitir el mensaje RACh 3 no se asignan a un terminal espedfico (es decir, el RNTI asignado solamente a un terminal espedfico), sino que se asignan usando un RNTI, que se puede usar simultaneamente por una pluralidad de terminales. Por lo tanto, si los recursos radio se asignan usando el RNTI compartido por una pluralidad de terminales, en lugar de un RNTI dedicado por terminal, se propone para incluir un LCID que se ha fijado con un valor especial en la cabecera de PDU de MAC a fin de indicar el mensaje RRC incluido en la PDU de MAC. Durante el procedimiento anterior, el valor especial usado para indicar el CCCH se puede notificar a traves de informacion de sistema o determinar para ser un valor fijo.
Ademas, la presente invencion propone, cuando la PDU de MAC se transmite a traves del mensaje RACH 3 en el procedimiento RACH, tener un formato de PDU de MAC diferente de un formato de PDU de MAC usado en otros casos. Es decir, hay casos para usar recursos radio asignados a un terminal espedfico solamente o recursos radio asignados usando un RNTI para un terminal espedfico y no para usar tales recursos radio. En tales casos, se usan diferentes formatos de PDU de MAC. Adicionalmente, cuando se usa un preambulo asignado solamente a un terminal espedfico, es decir, cuando se usa un preambulo dedicado en el mensaje RACH 1 y si la PDU de MAC incluida en el mensaje RACH 3 incluye el mensaje RRC, el LCID para indicar el mensaje RACH usa un valor fijado al terminal a traves del mensaje RRC. Ademas, a fin de que una entidad MAC del lado de recepcion determine facilmente la presencia de datos de CCCH en la PDU de MAC recibida, se propone incluir un indicador de formato en la cabecera de PDU de MAC. Es decir, el indicador de formato puede indicar si los datos incluidos en la PDU de MAC son o no los datos de CCCH. El LCID de CCCH puede indicar a la entidad MAC del lado de recepcion si datos incluidos en la PDU de MAC recibida se debenan procesar por la entidad MAC del lado de recepcion o la entidad RRC.
Las Fig. 8a y 8b ilustran campos de LCID ejemplares de una subcabecera de MAC usada segun la presente invencion. La Figura 8a ilustra valores de LCID para DL-SCH y la Figura 8b ilustra valores de LCID para UL-SCH. En las Fig. 8a y 8b, se incluyen indices para indicar el CCCH y puede existir un campo de LCID para cada SDU de MAC, elemento de control de MAC o relleno incluido en la PDU de MAC. Aqrn, un tamano del campo de LCID es 5 bits.
5
10
15
20
25
30
35
40
45
50
55
La presente invencion tiene un efecto de aumentar la eficiencia de transmision de datos sin causar consumo de potencia proporcionando un metodo para transmitir eficazmente informacion de canal logico de control comun cuando la entidad MAC genera la PDU de MAC.
La presente invencion puede proporcionar un metodo de generacion de una unidad de datos de protocolo (PDU) en un sistema de comunicacion inalambrico, el metodo que comprende: recibir al menos una unidad de datos de servicio (SDU) de una capa superior a traves de un canal logico comun; anadir una cabecera a las SDU recibidas para generar la unidad de datos de protocolo (PDU), en donde la cabecera incluye al menos un campo, en donde se usa el al menos un campo para identificar un canal logico o se usa para identificar un tipo de informacion de control; ajustar el al menos un campo para indicar que la al menos una de las SDU incluidas en la PDU generada se recibieron a partir del canal logico comun; y entregar la PDU generada a una capa inferior, en donde el canal logico comun es un canal de control comun (CCCH), el al menos un campo es un campo de ID de canal logico (LCID), el al menos un campo se fija con un valor especial, el valor especial se fija con 00000, el valor especial se fija para indicar un canal de control comun (CCCH), un tamano del al menos un campo es 5 bits, la PDU es una PDU de Control de Acceso al Medio (MAC) y la al menos una SDU es una SDU de MAC, el al menos un campo se usa para cada SDU de MAC, elemento de control MAC o relleno incluido en una PDU de MAC.
Aunque la presente invencion se describe en el contexto de comunicaciones moviles, la presente invencion tambien se puede usar en cualquier sistema de comunicacion inalambrico que use dispositivos moviles, tales como PDA y ordenadores portatiles equipados con capacidades de comunicacion inalambrica (es decir, interfaz). Ademas, el uso de ciertos terminos para describir la presente invencion no se pretende que limite la presente invencion a un cierto tipo de sistema de comunicacion inalambrico. La presente invencion tambien es aplicable a otros sistemas de comunicacion inalambricos que usan diferentes interfaces de aire y/o capas ffsicas, por ejemplo, TDMA, CDMA, FDMA, WCDMA, OFDM, EV-DO, Wi-Max, Wi-Bro, etc.
Las realizaciones ejemplares se pueden implementar como un metodo, aparato o arffculo de fabricacion usando programacion estandar y/o tecnicas de ingenieffa para producir software, microprograma, hardware o cualquier combinacion de los mismos. El termino “arffculo de fabricacion” como se usa en la presente memoria se refiere a codigo o logica implementada en logica hardware (por ejemplo, una pastilla de circuito integrado, Formacion de Puertas Programables en Campo (FPGA), Circuito Integrado de Aplicaciones Espedficas (ASIC), etc.) o un medio legible por ordenador (por ejemplo, medio de almacenamiento magnetico (por ejemplo, unidades de discos duros, discos flexibles, cinta, etc.), almacenamiento optico (CD-ROM, discos opticos, etc.), dispositivos de memoria volatil y no volatil (por ejemplo, EEPROM, ROM, PRoM, RAM, DRAM, SRAM, microprograma, logica programable, etc.).
Se puede acceder al codigo en el medio legible por ordenador y ejecutar por un procesador. El codigo en el que se implementan las realizaciones ejemplares puede ser accesible ademas a traves de un medio de transmision o desde un servidor de archivos sobre una red. En tales casos, el arffculo de fabricacion en el que se implementa el codigo puede comprender un medio de transmision, tal como una lmea de transmision de red, medios de transmision inalambricos, senales que se propagan a traves del espacio, ondas radio, senales de infrarrojos, etc. Por supuesto, los expertos en la tecnica reconoceran que se pueden hacer muchas modificaciones a esta configuracion sin apartarse del alcance de las reivindicaciones adjuntas y que el arffculo de fabricacion puede comprender cualquier medio portador de informacion conocido en la tecnica.
Cualquier referencia en esta especificacion a “una realizacion”,
La capa ffsica (Capa 1) usa un canal ffsico para proporcionar un servicio de transferencia de informacion a una capa superior. La capa ffsica se conecta con una capa de control de acceso al medio (MAC) situada por encima de la misma a traves de un canal de transporte y los datos se transfieren entre la capa ffsica y la capa MAC a traves del canal de transporte. Tambien, entre diferentes capas ffsicas respectivamente, esto es, entre las capas ffsicas respectivas del lado de transmision (transmisor) y el lado de recepcion (receptor), se transfieren datos a traves de un canal ffsico.
La capa de Control de Acceso al Medio (MAC) de la Capa 2 proporciona servicios a una capa de control de enlace radio (RLC) (que es una capa superior) a traves de un canal logico. La capa RLC de la Capa 2 soporta la transmision de datos con fiabilidad. Se debeffa senalar que si las funciones RLC se implementan en y realizan por la capa MAC, la capa RLC en sf misma puede no necesitar existir. La capa PDCP de la Capa 2 realiza una funcion de compresion de cabecera que reduce informacion de control innecesaria de manera que los datos que se transmiten empleando paquetes de Protocolo de Internet (IP), tales como IPv4 o IPv6, se pueden enviar eficientemente sobre una interfaz radio que tiene un ancho de banda relativamente pequeno.
La publicacion de solicitud de patente de EE.UU. N° 2006/067364 A1 describe un esquema de procesamiento de Capa de Acceso al Medio (MAC) para minimizar el tamano de informacion de correlacion contenida en una PDU de MAC.
La Especificacion Tecnica del 3GPP TS 36.321, V1.0.0, es una especificacion tecnica del 3GPP de un protocolo MAC para redes eUTRA.
El borrador del 3GPP N° R2-073891, titulado “MAC header format, R2-073891”, describe formatos propuestos para la cabecera de mensajes de datos MAC y la cabecera de mensajes de control MAC en un sistema de comunicacion inalambrico del 3GPP.
La capa de Control de Recursos Radio (RRC) situada en la parte mas baja de la Capa 3 se define solamente en el 5 plano de control y maneja el control de canales logicos, canales de transporte y canales ffsicos con respecto a la configuracion, reconfiguracion y liberacion de portadores radio (RB). Aqm, el Rb se refiere a un servicio que se proporciona por la Capa 2 para transferencia de datos entre el terminal movil y la UTRAN.
Los RB se refieren a un camino logico proporcionado por la primera y segunda capas del protocolo radio para transmision de datos entre el terminal y la UTRAN. En general, configuracion (o establecimiento) del RB se refiere al 10 proceso de estipulacion de las caractensticas de una capa de protocolo radio y un canal requerido para proporcionar un servicio particular y establecer los parametros detallados respectivos y metodos operacionales. Un estado RRC se refiere a si existe una conexion logica para intercambiar mensajes RRC entre la capa RRC de un terminal espedfico y la capa RRC de la UTRAN. Si hay una conexion, el terminal se dice que esta en estado conectado RRC. Si no hay conexion, se dice que el terminal esta en estado inactivo.
15 El canal logico es un canal definido entre una entidad RLC y una entidad MAC y se puede dividir segun las caractensticas de datos en el canal logico. El canal de transporte es un canal definido entre la capa ffsica y la entidad MAC y se puede dividir segun un esquema de transmision en el que se transmiten los datos en el canal de transporte.
En general, el Canal de Control Comun (CCCH) es un canal de control comun y se usa cuando un terminal envfa un 20 mensaje a una estacion base en un estado en que el terminal no tiene una conexion RRC con la estacion base o cuando un terminal envfa un mensaje RRC en un estado que el terminal tiene una conexion RRC con una cierta base
Claims (7)
- 510152025REIVINDICACIONES1. Un metodo de generacion de una unidad de datos de protocolo, PDU, en un sistema de comunicacion inalambrico que comprende terminales, el metodo que comprende:recibir al menos una unidad de datos de servicio, SDU, desde una capa superior a traves de un canal logico comun,en donde el canal logico comun es un canal de control comun, CCCH; anadir una cabecera a las SDU recibidas para generar la PDU, en donde la cabecera incluye al menos un campo,en donde el al menos un campo identifica un canal logico de la SDU recibida o un tipo de elemento de control, CE;establecer el al menos un campo para indicar que la al menos una de las SDU incluidas en la PDU generada se recibieron desde el canal de control comun,en donde un mdice dentro del al menos un campo se fija con un valor fijo aplicado a todos los terminales para indicar el canal de control comun yentregar la PDU generada a una capa inferior.
- 2. El metodo de la reivindicacion 1, en donde el valor fijo se fija con 00000.
- 3. El metodo de la reivindicacion 1, en donde la PDU es una PDU de Control de Acceso al Medio, MAC y la al menosuna SDU es una SDU de MAC.
- 4. El metodo de la reivindicacion 1, en donde un tamano del al menos un campo es 5 bits.
- 5. El metodo de la reivindicacion 1, en donde el al menos un campo es un campo de ID de canal logico, LCID.
- 6. El metodo de la reivindicacion 1, en donde el al menos un campo se usa para cada SDU de MAC, elemento de control MAC o relleno incluido en una PDU de MAC.
- 7. Un aparato de estacion base en un sistema de comunicacion inalambrico que comprende terminales, el aparato de estacion base que comprende un procesador configurado para realizar un metodo de generacion de una unidad de datos de protocolo, PDU, segun cualquiera de las reivindicaciones 1 a 6.
Applications Claiming Priority (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US19575 | 1987-02-27 | ||
| US98212007P | 2007-10-23 | 2007-10-23 | |
| US982120P | 2007-10-23 | ||
| US98330407P | 2007-10-29 | 2007-10-29 | |
| US983304P | 2007-10-29 | ||
| US1888408P | 2008-01-03 | 2008-01-03 | |
| US18884 | 2008-01-03 | ||
| US1957508P | 2008-01-07 | 2008-01-07 | |
| KR20080101329A KR101487557B1 (ko) | 2007-10-23 | 2008-10-15 | 공통제어채널의 데이터를 전송하는 방법 |
| KR20080101329 | 2008-10-15 | ||
| PCT/KR2008/006199 WO2009054655A2 (en) | 2007-10-23 | 2008-10-20 | Method for transmitting data of common control channel |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2565836T3 true ES2565836T3 (es) | 2016-04-07 |
Family
ID=43543799
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08842001.3T Active ES2565836T3 (es) | 2007-10-23 | 2008-10-20 | Método para transmitir datos de canal de control común |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JP5042368B2 (es) |
| ES (1) | ES2565836T3 (es) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9215731B2 (en) | 2007-12-19 | 2015-12-15 | Qualcomm Incorporated | Method and apparatus for transfer of a message on a common control channel for random access in a wireless communication network |
| CN101931872B (zh) * | 2009-06-26 | 2015-04-01 | 中兴通讯股份有限公司 | 一种mbms中的逻辑信道标识传输方法和系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8817737B2 (en) * | 2005-10-31 | 2014-08-26 | Lg Electronics Inc. | Method of transmitting and receiving data in a mobile communication network |
-
2008
- 2008-10-20 ES ES08842001.3T patent/ES2565836T3/es active Active
- 2008-10-20 JP JP2010527899A patent/JP5042368B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP5042368B2 (ja) | 2012-10-03 |
| JP2010541464A (ja) | 2010-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2206254B1 (en) | Method for transmitting data of common control channel | |
| ES2997376T3 (en) | Method for handling non small data transmission radio bearer during small data transmission and apparatus thereof | |
| RU2730584C1 (ru) | Способ и устройство для передачи единицы данных | |
| ES2602957T3 (es) | Método para señalizar información de retroceso en acceso aleatorio | |
| CN101473565B (zh) | 在无线移动通信系统中使用消息分离发送和接收无线电接入信息的方法 | |
| CN115442775B (zh) | 数据传输的方法、终端设备和接入网设备 | |
| ES2735625T3 (es) | Procesamiento de búsquedas mediante un servidor que gestiona la movilidad para evitar, en caso de fallo en la búsqueda, la pérdida de los datos de enlace descendente almacenados temporalmente en una pasarela de servicio | |
| EP2442618B1 (en) | Method for a user terminal to random access a carrier aggregation mobile communication system | |
| ES2376719T3 (es) | Método para enviar mensajes rrc en un sistema de comunicaciones inal�?mbricas. | |
| ES2724802T3 (es) | Procedimiento y aparato de transmisión/recepción de datos en un sistema de comunicación móvil | |
| KR20150013453A (ko) | 데이터 패킷들의 업링크 및 다운링크 동안 비연결형 전송을 위한 방법 및 시스템 | |
| KR20130093774A (ko) | Pdcp 패킷 전송 방법 | |
| KR20070121567A (ko) | Rrc 접속 요청 메시지를 분리하여 전송하는 방법 | |
| JP2014511168A (ja) | 移動体通信ネットワークおよび方法 | |
| KR20180099732A (ko) | 데이터 수신 방법 및 사용자기기와, 데이터 전송 방법 및 기지국 | |
| CN106954280B (zh) | 一种数据传输方法、装置及系统 | |
| CN110351882A (zh) | 一种请求系统信息的指示方法、相关设备及系统 | |
| US11497061B2 (en) | Method and apparatus for performing random access procedure for unlicensed band n wireless communication system | |
| CN115665882A (zh) | 用于传送临时标识符的方法和系统 | |
| KR20090041323A (ko) | 데이터 블록 구성함에 있어서 단말의 식별 정보를 효과적으로 전송하는 방법 | |
| US10973080B2 (en) | Radio terminal, processor, and base station | |
| ES2565836T3 (es) | Método para transmitir datos de canal de control común | |
| US11057947B2 (en) | Radio network temporary identifier generation | |
| CN119032601A (zh) | 无线通信方法、用户装备和基站 | |
| CN118318490A (zh) | 终端装置、方法以及集成电路 |